Jon Seidel wrote
I'd call myself an "advanced perl newbie" if a label
> makes you happy :)
Arent we all? :)
> However, this means that you have to 'switch' run
> modes to transfer control from the post-processing run mode of the
> current screen to the pre-processing run mode of the next screen. I
> found out how to do that "runmode switch" from Mark Fragassi's
> "Tutorial Slideshow" on the CGI::App Best Practices website.
>
> However, if you accept the approach of using paired run modes and
> mode-switching, that leads you to a concept that I refer to as
> "Screen modes". The Screen Mode is a combination of the pre-
> processing run mode, the user/screen interaction, and the post-
> processing run mode, all for a single screen. It just helps me
> organize what's happening and assign meaningful names (For example:
> screen = A.html, pre-runmode = A_form, post-runmode = A_process).
> This definition helps me better map a CGI::App onto the Model-View-
> Controller design pattern (also discussed in the Tutorial Slideshow)
> . Essentially, the 'View' becomes A_form and 'Controller' becomes
> A_process, with a runmode switch ( or 'ScreenMode switch' to go from
> A_process to B_form and the next screen in the sequence.
>
I think you may be complicating the run_mode approach. I agree that you should
associate two run modes with a screen. The 'Viewer' and the 'Modeler' or show
and process. I think you don't need the 'post-processing' mode since this is
just the 'Viewer' of another screen. I'm sure what you mean by
'mode-switching'. If you do it right, all you have to do is return the next
mode. For instance, using your example, I show A.html with the 'A_form' mode.
The data is handled by the 'A_process' mode. Then the uses is taken to the
'B_form' mode.
your A_process mode should look something like this...
sub A_process
{
my $self = shift;
#do all my processing
#.
#.
#now go to the B_form mode
return $self->B_form();
}
sub B_form
{
my $self = shift;
#do anything I need to do to show the form
#.
#.
return $output;
}
> Does this work in general? Or do you run into situations where the
> "post-processing" run mode has to choose between two or more
> possible mode switches and therefore has to have more knowledge
> about the application flow? Seems to me there will be a situation
> where that is the case and then you'll have to have a set of if/else
> structures and other data to determine where you want to transfer
> control (see next question, too).
If you follow the above example that I gave than if you need to decide where
to go after you process A you can let 'A_process' do that since it already has
the info about A.
If you haven't guessed, I also like the Model-View-Controler methodology. If
you missed my previous post today, that's what our whole CheesePizza structure
is based on (especially the Venzia::CRUD base class
http://cheesepizza.venzia.com/modules/Venzia/CRUD.pm
.
http://cheesepizza.venzia.com
http://cheesepizza.venzia.com/docs
> Q2: I intend to have folks login for any access to my website;
> however, if I were to include a 'Guest' (no login required) option,
> then I'd have to go to the Login screen from several different
> (restricted) places and then return to the screen which forced the
> login. I believe this is a situation where the 'switch modes'
> operation is not straight-forward: there is some "post-processing"
> required (verify that the login is correct), yet there are any
> number of different screens that you will want to return control to.
> Seems to me that the runmode concept gets a little twisted here. I presume
> that I invoke the Login mode via the cgiapp_prerun() method if the
> user is not already logged on(?),
If you do your authorization in a users/groups manner then you can have your
admin groups also have access to the elements that don't require a login. Both
the 'Guest' group and the other admin groups can have access to the public
stuff and only the admin groups will have access to the admin stuff.
>but what's the best way to handle
> the transfer of control once the person has logged in and is ready
> to continue working on the screen they initially selected?
usually a redirect of some sort. You would remember where they wanted to go
and then redirect to there.
> Q3: What are the trade-offs around using forms/submit buttons or
> href links to specify the run mode that will be invoked from a
> screen? If you use forms, is it preferable to use one form for the
> entire screen and then use Javascript's onClick function to set the
> run mode variable or to use multiple forms, each of which contains
> their own run mode hidden variable and a specific submit button? Are
> there any other mechanisms that people use to set the runmode variable?
As a rule I try to avoid Javascript wherever possible since it can be turned
off and/or function differently. I use multiple forms on a page. This way I
can, at a glance, make sure that my run mode is getting everything it needs
without having to debug any javascript when something doesn't get back to the
server side. I also use <A HREF>s too since they will carry the same data to
the script.
HTH
Michael Peters
Venzia
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/cgiapp@xxxxxxxxxxxxxxxxx/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: cgiapp-unsubscribe@xxxxxxxxxxxxxxxxx
For additional commands, e-mail: cgiapp-help@xxxxxxxxxxxxxxxxx
|
