Quoting Mark Stosberg <[EMAIL PROTECTED]>:
> 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.
Hello all,
Jesse's and Mark's examples are also how I have worked through this issue. In
my project "WebPageWizard", there are cases where more than one action is needed
before returning output. In Christopher's and Elizabeth's comments, they asked
for better ways of doing run_mode/run_mode/print. Well, sometimes I needed
run_mode/run_mode/run_mode/print, or worse.
My run_modes were large and bulky, and communicating between them got very
frustrating. I realized that this was a design problem with my code because I
was duplicating code in a lot of places. So I started to break my code up into
essentially two categories: subroutines that return HTML, and those that
get/store data. I noticed that I didn't need every subroutine to be a run_mode.
Some could be just functions that I call from a run_mode (or many run_modes).
My run_modes became much smaller, and my code became much more object oriented.
Instead of linking run_modes together, each run_mode stands alone but makes
several calls to supporting functions. I still have a lot of work to do on my
project, but it has gotten better with this approach.
I relate to what you are trying to do. But I also think that the design of
CGI::App lends itself to this kind of breakdown of run_modes and support
functions. Make only those routines that return HTML to the browser into
run_modes, all others should simply be support functions to those run_modes.
I have great respect for all who contribute to this mail list, and am learning a
lot from you all. I hope that my response has helped a little bit.
-spencer christensen
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
