[Catalyst] The Real Handel Scaffold :-)

[Christopher H. Laco]

Now that my evil hackery towards the demo is out of the way, I wan't to 
start working on the real slim shady. My goal is to modularize my 
scaffold into seperate helpers that work on their own, and can also all 
be called within the scaffold [using mk_component] to make the entire 
package.

I'm working under two premises.

First, I'm a firm believer that a controller should never create tt 
pages or models. That's the job of the view/model commands. I think I 
need to relearn that assumption. I'm starting to think the oppositel 
that the controller is the hub and creates everything it needs to work.

Second, I'm working under the assumption that this will only work well 
if it's generating controllers that will be accessed by their Local uri 
and not via any Global methods. That may not be true, but I just can yet 
wrap my brain around the solution and the possible variations.

Here's my first idea:

	create.pl controller ClassName Handel::type [args]

		controller Cart Handel::Cart
		controller Order Handel::Order
		controller Checkout Handel::Checkout

	create.pl Handel::Scaffold dsn user pass
	
Now for the breakdown:

*controller Cart Handel::Cart

This creates the specified cart controller that contains the appropriate 
Local methods like add, update, delete, clear, save, restore, etc. It 
creates the cart template files and the model as well.

*controller Orders Handel::Order creates the order stuff like the cart 
stuff.
*controller Checkout Handel::Checkout creates the checkout 
controler/templates.

Here's my struggle. mk_component does a good job of abstraction the .pm 
file names, putting them in the right locations, dealing with filenames 
and directories, and making the correct package name in the file, etc.

mk_component only works well if you have a helper to reference. In the 
above scenerio I don't really have them. Should I make them even though 
people should never use them directly like this?

	create.pl controller MyApp::Cart Handel::Cart
	
	(which internally calls)
	
	mk_component('MyApp', 'model', 'Cart', 'Handel::Cart')
	
	(which in tern calls Catalyst::Helper::Model::Handel::Cart)
	
	I wouldn't expect someone tu do:
	
	create.pl model Cart Handel::Cart dsn user pass
	
	although I think they could with no ill effects...

Then, the scaffold is literally:

	mk_component('MyApp', 'controller', 'Cart', 'Handel::Cart')
		#which also creates it's model/templates
	
	mk_component('MyApp', 'controller', 'Order', 'Handel::Order')
		#which also creates it's model/templates
		
	mk_component('MyApp', 'controller', 'Checkout', 'Handel::Cart')
		#which also creates it's model/templates

Clear as mudd right? Seens nice and modular. The one think I learned 
from the demo scaffold is that doing all that path junk on your own 
seems like reinventing the wheel compared to the internal magick of 
mk_component.

-=Chris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3178 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.rawmode.org/pipermail/catalyst/attachments/20050830/dac8a8cb/smime.bin