> Instead of putting this in the run() method, what if you created a single
> run-mode which ran your entire application?  Call it "ubermode":

Actually...that isn't what I'd want personally.

As you noted in a later email, this eliminates most of the CGI::Application
benefit, there would still need to be a decision tree further down.

>       sub setup {
>               my $self = shift;
>               $self->run_modes(
>                       'ubermode' => \&ubermode
>               );
>               $self->start_mode('ubermode');
>       }

What I'd like is the controller to do more than just dispatch to an action
and expect the action will return output to the browser. I'd like it to both
dispatch to an Action/Run-Mode, and then accept the return of that Action
and chain to additional Actions/RunModes or to OutputModes as specified by
my config.

WARNING - I got on a roll describing this so there is a LOT of text below.
Read at your peril. ;-) <grin>

Something like this:
        sub setup {
                my $self = shift;
                # This is normal -> nice mapping of request param to run_modes/actions
                $self->run_modes(
                        'Menu'       => \&ActionMenu,
                        'WidgetForm' => \&ActionWidgetForm,
                        'SaveWidget' => \&ActionSaveWidget);

                # Pseudo-code for mapping results of actions to either Views or 
additional
Actions
            # This could be hard coded, or as in
jakarta.apache.org/struts -> read from a config file.
                $self->output_modes(
                        'ActionMenu:success'          => \&ViewMenu,          #Show 
the Menu
HTML
                        'ActionWidgetForm:success'    => \&ViewWidgetForm,    #Show 
the Form
HTML
                        'ActionSaveWidget:success'    => \&ActionMenu,        #Save 
widget,
return to menu
                        'ActionSaveWidget:success_add'=> \&ActionWidgetForm,  #Save 
widget, then
add another one
                        'ActionSaveWidget:errors'     => \&ActionWidgetForm); #Errors 
in form,
try input again.
        }

And then when the run_mode are dispatched here are some Use Cases:

1) User wants to see the Menu
rm=Menu
Dispatcher sends request to ActionMenu()
ActionMenu creates stuff from a database for use the context used eventually
by the output template
ActionMenu returns "success"
Dispatcher looks up what to do - finds ActionMenu:success -> calls
ViewMenu()
ViewMenu creates some standard formatting things (ex. creates navigation
items) , combines them with the stuff already in the context, and calls
HTML::Template parse.
ViewMenu returns HTML output.
Request is complete.

2) User adds a Widget with a form (non-chained action)
rm=WidgetForm
Dispatcher sends request to ActionWidgetForm()
ActionWidgetForm creates stuff from a database for use the context used
eventually by the output template
ActionWidgetForm returns "success"
Dispatcher looks up what to do - finds ActionWidgetForm:success -> calls
ViewWidgetForm()
ViewWidgetForm creates some standard formatting things (ex. creates
navigation items) , combines them with the stuff already in the context, and
calls HTML::Template parse.
ViewWidgetForm returns HTML output.
Request is complete.

3) User saves Widget, validation fails. (chained action->action->view)
rm=SaveWidget
Dispatcher sends request to ActionSaveWidget()
ActionSaveWidget validates the input data, and notices errors "Price >
$5,000" so it sticks an array of errors into the context for eventual
template display.
ActionSaveWidget returns "errors"
Dispatcher looks up what to do - finds ActionSaveWidget:errors -> calls
ActionWidgetForm() (another action)
ActionWidgetForm creates some standard formatting things (ex. creates
navigation items) , combines them with the stuff already in the context (ie.
the errors) and returns "success".
Dispatcher looks up what to do - finds ActionWidgetForm:success -> calls
ViewWidgetForm()
ViewWidgetForm creates some standard formatting things (ex. creates
navigation items) , combines them with the stuff already in the context, and
calls HTML::Template parse.
ViewWidgetForm returns HTML output.
Request is complete.


4) User saves Widget, validation succeeds, and they want to add another
widget. (chained action->action->view)
rm=SaveWidget
Dispatcher sends request to ActionSaveWidget()
ActionSaveWidget validates the input data, saves to database, and notices a
submit parameter "Save and Add Another"
ActionSaveWidget returns "success_add"
Dispatcher looks up what to do - finds ActionSaveWidget:success_add -> calls
ActionWidgetForm() (another action)
ActionWidgetForm creates some standard formatting things (ex. creates
navigation items) , combines them with the stuff already in the context (ie.
the errors) and returns "success".
Dispatcher looks up what to do - finds ActionWidgetForm:success -> calls
ViewWidgetForm()
ViewWidgetForm creates some standard formatting things (ex. creates
navigation items) , combines them with the stuff already in the context, and
calls HTML::Template parse.
ViewWidgetForm returns HTML output.
Request is complete.

----

So from that long-winded/typed treatise, do you see where/how I'd love to
see CGI::Application to do MORE of the nice things it does for me instead of
less? :-)


Cheers,
Timothy




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

Reply via email to