Jesse - > > I'm trying to move runmode subs, which I'm going to call > > 'actions', into their own class/file/package. > Why do that? I noted in the original post a couple that came off the top of my head, ex. separate CVS files so different developers can work on different run-mode actions, actions could inherit common functionality from their own base class Action.
> If you're interested in the Model-View-Controller (MVC) design pattern, > think of CGI::Application as the "Controller". Thanks - I am thinking that way. :-) > As such, any code which > interacts with the CGI request or form data should be in your Application > module. That would include your run-mode methods. I've been heads down for a while in the Struts paradigm - I'm trying to style the CGI code in a similar fashion to the good bits from that paradigm. One thing that I've noticed is that after moving the run-mode actions into their own classes -> what's left of the Controller is setup, dispatching, and teardown. Indeed, in Struts, this class is a library unseen by developers which configures itself from an XML file that specifices which classes handle which actions, and what View the Action should produce upon the success/fail/other_status of the action. "If you love Struts so much, why are you working with CGI::Application, Tim?" Heh heh - Perl rocks :-) And since we have some legacy Perl CGI's that are ugly, CGI::Application and HTML::Template are a fine way, IMHO, to improve them. As I said - I'm just researching howto borrow good bits of paradigm. :-) > Your "Model" (the back-end business logic) could easily be stored in a > separate module and used by your Application module. Consider the > following: > # Use your "Model" > use BusinessLogic; That's a good idea - it's similar to what we're doing in our project - each action instantiates bits of the business model as required. As Mark noted - the controller app can still get big. Even without a lot of run_modes -> each run_mode action may perhaps have similar repeated non-business-logic code (ex. handling Navigation, user authorization), so I like the idea of a class for Actions which has common stuff rolled into a base class. I don't like to over-engineer stuff though - so for now I'm going to fall back to using 'require ActionThingy.pl' to accomplish my primary goal of separate files for CVS reasons. :-) After I've spent some time to gain experience actually building real CGI::App code, I'll see if I should return to the separate Action class paradigm and refactor. BTW - MOD_PERL is not an option for this environment, so some points may be moot as I move to servlets to gain a single run-time instance and pooled DB connections. However, for any projects that still use Perl, I plan to standardize on CGI::App. Cheers, Tim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
