Jesse,
>
> 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?)
>
This would be exactly my point - the choice of the next screen is dynamic.
One thing it might depend on is navigation history, ie what was the user
doing before he got to the save data screen. Maybe it would be nice to send
him back to where he came from. But, let's be general. There is persistant
data being carried from screen to screen using Apache::Session or whatever
and the screen needs to be chosen dynamically based on the state of one or
more of those variables.
> 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".
>
Did anyone notice that I called CGI-App a finite state machine in my other
post? Does anyone have a comment about this? Well, let's say that CGI-App
is a good implementation of an FSM. So possibly I am in the wrong "problem
domain" because I am looking at things from a "solution domain" point of
view? Hmmm - I hadn't really thought of it that way before. Put it this
way. Right now, if I go off to write my own module to solve this problem,
it will look a whole lot like CGI-App with configurable output.
Here is another thought from out of the wild, blue yonder. Both CGI.pm and
CGI::FormBuilder leave the exact moment that the print takes place for the
programmer to decide. I am biased to see these as similar to CGI-App
probably because I use all three. Is there any similarity?
Elizabeth
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
