Jesse -
> > rm(SaveData)->rm(ProductMenu)->output(ProductMenu w/ standard leftnav)
> I think what you have here could be constructed in a different way
> 1. User is on Edit Form. They click "SAVE".
> 2. The run-mode "update_record_and_return_to_menu" is called:
That would put bind the decision of what to do next to the form itself. As I
said, "SaveData" doesn't know where it's going next. It might produce an
error page, a product menu, or perhaps this was a two-part edit and so it
needs to go to EditForm #2.
> What could be simpler than this? "SaveData" isn't really a run-mode.
I think there's part of the point... for simple cases, this isn't a problem.
The complex runmode/actions which are where it becomes a problem.
> It's
> more like a support function. If you are an MVC enthusiast, "SaveData" is
> probably an excellent candidate for inclusion into a "Model" class which
> might actually be used by other applications.
SaveData does indeed update the business objects (model) and then asks them
to save themselves.
SaveData is likely a very small runmode, but a runmode none the less.
If it wasn't a runmode, where do you send the form to??
Form->runmode(?)
> The only possible modification to my understanding of your problem I can
> imagine is if you told me that clicking save on the Edit Form
> doesn't always return you to the Product Menu.
That's the exact situation.
> In which case I ask: What decides where the user goes next?
> 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();
> }
Yep - that's pretty much it.
> Your dynamically_choose_next_screen() would then have some switch to send
> the user somewhere based on some logic.
Well... again, at the risk of 'pushing the decision around'... my rm would
return only "success" or "failure" tokens. The appframework which called
called the rm would then decided what to do based on those tokens. (more on
this
> (Out of curiosity, what might that logic be?)
Not to advocate it's "The Way".. but how it's done in Jakarta Struts is that
there is a config file that says (paraphrasing):
For this RunMode/Action("widget/save.do"), it is handled by an Action class
com.foo.bar.WidgetSave which implements doPerform(), doPerform() will always
return a result token, that token will be resolved into the next step and
can either be a RunMode/Action or a View.
<!-- Widget Save -->
<action path="/widget/save.do"
type="com.foo.bar.WidgetSave">
<forward name="success" path="/widget/editPage2.do"/>
<forward name="errors" path="errorPage.tpl"/>
</action>
> I don't want to sound resistant to modifying CGI-App -- I'm not! I just
> want to make sure that I don't add features which, perhaps, are in another
> "problem domain".
I understand. :-) Kinda like the threads I saw a lot on the HTML::Template
forums where somebody says, "Gee Sam, this is great, but can't you add
feature Foo?" And 99% of the time, Sam says, "Uh.. nope. That's for the app
to do, not the template module." To which 99.99% of the time I agree. :-)
I'm not actually asking for you to change things. I'm just offering my
opinion that this rm->rm->output chaining concept merits at minimum a
thoughtful consideration, something I'm sure you'll give it. :-)
Cheers,
Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
