Hi Tim --
> I came up with this concrete example for 'rm->rm->output' :
> A product edit form calls rm-SaveData to save stuff -> then needs
> to display
> a product menu (rm=Menu)
>
> rm(SaveData)->rm(ProductMenu)->output(ProductMenu w/ standard leftnav)
I think what you have here could be constructed in a different way. For
instance:
1. User is on Edit Form. They click "SAVE".
2. The run-mode "update_record_and_return_to_menu" is called:
sub update_record_and_return_to_menu {
my $self = shift;
$self->save_data();
return $self->product_menu();
}
What could be simpler than this? "SaveData" isn't really a run-mode. 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.
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. In which case I ask: What decides where the
user goes next? It has to be decided by something! Either it is statically
defined (during product specification, most likely) as I have illustrated,
or it is dynamically chosen based on some other logic.
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();
}
Your dynamically_choose_next_screen() would then have some switch to send
the user somewhere based on some logic. (Out of curiosity, what might that
logic be?)
Does this not accommodate what you and Elizabeth are describing, without
changing the fundamental behavior of CGI-App?
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".
Thoughts?
-Jesse-
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
