Gang - Catching up after some PTO on the list...this thread interests me as I'm now working on some bits that are similar.
> > Okay, so let me see if I'm understanding this with a short example: > > You have three Actions, ACtionA, ActionB, and ActionC. > > You have three screens ScreenA, ScreenB, ScreenC. > > OVerall, the Screen and the Action have no relation. > > If so, it sounds like you have problem with the single Run mode param. > > Have your run modes do the appropriate Action, based on the > > runmode. Each > > run mode returns $self->EvaluateAction() which is a routine > > that looks at > > another param and returns the appropriate screen (or > > HTML::Template call) Hmm... I might have a slight twist on that depending on how one reads the word "param". Some of the thread seems to indicate that "param" is a CGI request param - ex. ?rm=showdetail&screen=online vs. ?rm=showdetail&screen=printable The idea of choosing/using different HTML::Templates seems to fit nicely there. The 'action' is always the same 'showdetail' so the data stuffed into the response context will be the same. The output simply varies. Another way to read it is that the "param" is a variable parameter determined by the action. - ex. ?rm=savechanges -> if 'success' - returns the output of 'confirmation.tpl' -> if 'error' (during form validation) - returns the output of partially filled-in 'editform.tpl' with additional mesg. "Please fill in the blank." In this case, the depending on the outcome of the server-side form data validation... the action needs to stuff DIFFERENT things into the response context...AND choose a different template. ---- FYI: This paradigm is displayed in the jakarta.apache.org/struts project, implemented via a config file. One handy aspect is that an action can result in either a 'screen' or another 'action'. This is awfully nice when you are 'saving' -> and the 'success' path result is actually to forward the call to the "MainMenu" action...which has a 'success' result of "menu.tpl". BTW - I personally would -not- advocate having a CGI param dictating the "next" action. I feel that each action/run-mode should always determine what's 'next'. However, it seems useful to have the loose coupling of action-result by specifying this in a config file. (ex. a set of wizard screens that goes Step 1,2,3,4... and you decided you want them 1,4,3,2). Food for thought :-) Cheers, Tim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
