Jesse Erlbaum wrote:
> 
> If it is dynamic, your run-mode maybe looks like this:
> 
>         sub update_record_and_return {
>                 my $self = shift;
> 
>                 $self->SaveData();
> 
>                 return $self->dynamically_choose_next_screen();
>         }


This what I do in Cascade ( http://summersault.com/software/cascade ),
and I've been really happy with this. Now that I can see the project as
a "complete" thing, there are some things I would change about my
structure of it (use more instance scripts with small run-mode modules),
but I would keep this design:
 
* Some modules contain run modes and a sub-class of CGI::App and some
modules are what I think of as "Data" modules, they are OO and not a
subclass of CGI::App. In my project my two primary types of objects are
"Categories" and "Items". I have Category.pm and Item.pm, which
generally translate between the database and something handy for
CGI::App (often a param hash that can be passed directly to
HTML::Template. 

So several run modes could call $item->update and that method will never
return output to the browser (even it fails, the caller should handle it
and return it's own error message). 

So with this structure, the actions I perform on objects are decoupled
from the resulting output. 

[ thinks for a moment ]. The one place in this structure that feels
slightly awkward is when I want to return not just a Perl data hash, but
some chunk of HTML for later re-use (like a single formatted item).
Because my Data module isn't a subclass of CGI::App, I don't have
load_tmpl() available to fire up HTML::Template with the same
parameters. For now I'm solving that by having the H::T connection
parameters in a config file that both kinds of modules can access. 

Perhaps ther's a way I could call load_tmpl() form the other module
without inheriting from it. 

Tangentially, there's a new feature in the beta version of Cascade that
some of you may be interested in: I added support for "Dynamic Item
Types"-- the ability to use your own data model for the items in the
database. The current implementation of this requires that still have to
be a programmer to set up a new item type (add a row in the database,
alter the data model, set up a display and form templates, as well as
it's own validation routine, and a customized output routine if you
want. [not to mention this is all only documented by example at the
moment.:) ]). The latest version in CVS also adds support for items
possibly having a thumbnail image upload field as one of it's
attributes. While I use this to power Skatepark.org, it would be at home
running a links index, or functioning as the content management part of
a e-commerce site. It also has that smart auto-redirect authentication
built in that other people have mentioned. 

  -mark 

 . . . . . . . . . . . . . . . . . . . . . . . . . .
   Mark Stosberg              Principal Developer  
   [EMAIL PROTECTED]       Summersault, LLC     
   v: 765-939-9301 ext 223    website development  
 . . . . . http://www.summersault.com/ . . . . . . .

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to