"nah, you gotta control the users path. Lead them by the nose or they will get it all wrong!". This would mean a rewrite to allow each run_mode to pass the user directly to one and only one run mode for the next phase.

You could have a separate run mode just for validation

present_form ->
  validate_form -> success
                -> present_form
[download]

If it's a set of forms (multiple pages to submit, you have to store the session on the server), then a group of run modes is reccomended (each successfull submit leading to the next form/run_mode).

One of my questions is this: should run-modes be kept should and simple perhaps handling only a part of a sungle site function? For example, for an administrator to select and view user profiles, should the saearch, select, view and edit each be a separate run_mode or is it, in your opinion, okay to combine them into one run_mode?

PodMaster

What my friend is saying is that the user should be taken along a siungle path through each major functional area of the site - that they should not be allowed the flexibility of registering at, say a tour level, but they need to provide more data into their user profile before they can use the full functionality (my scheme!) Thats one issue out of the way.

My reason for grouping actions together is this: Each of my current run modes uses a single template (well, really a page template for the overall look, a navigation template that gives the relevant navigation for the current action and a form template that actually contains the form). I am using CGI::FormBuilder to render the forms - becuase it gives me an easy way of loading defaults, requiring a field and validating field values. The same form is used for 'new entry', 'display record' and 'update record' functions purely by changing the buttons below the form (part of what FormBuilder does very easily). So by the PodMaster rule of ONE TEMPLATE ONE RUN-MODE I am still on the correct path.

I have been thinking about this for a coupole of hours over dinner now. One of the things I like about some websites is they give me the option of being able to browse without logging in. Just like PM does! So I want to be able to pop up my login form, the user can log in, and then they can go on from where they left off.

Session management is important as has been stated in another reply, I am using CGI::Session and storing the users entire state in the session. So I start a session before there is even a log-in attempt. My reasoning for this is that I can have a 'BACK' button that works within the application. I can read the session, find out where 'BACK' would take them, and then even query the database if necessary to fill out a form with valid values rather than using the browser back button and the difficulties attendant upon that. It also means I can be much more logical, if a 'BACK' move would take an already registered client to the form where he built his registration profile - well, he doesn't want to register again does he! We could take him to an 'edit profile' version of the same form.

jdtoronto

You said:

This is a UI decision, which depends closely upon what you are trying to accomplish. Sometimes it is appropriate, othertimes no. In terms of CGI:A and how you code, it doesn't really matter, as you could support either. Supporting a lot choices is easy, just have them encoded in hrefs in the returned html. If you want to force the user on a path, just give them html that contains only a submit button with a hidden rm field indicating the next runmode.

This is one of the things I thought about this evening. You are right. On the basis of what the client paying for the job wants I can modify the navigation system very easily without having to modify the code more than trivially.

Should "search, select, view and edit each be a separate run_mode"? Yes, in my opinion they should be seperated. Keep in mind that you can always factor out common code into an outside module for reuse across these runmodes.

I keep thinking about this and I am becoming more and more of the view that they can and perhaps in some cases should be grouped. This keeps all of the code associated witha single template inside a single run_mode which could itself ultimately be made into a module of its own.

A few weeks ago at the Toronto Perl Mongers, Richard Dice presented a talk on an application framework he built using CGI::Application, Template Toolkit and Class::DBI. He spoke of doing something that at the time I did not understand. His idea was that you subclass CGI::A and then create a module which has all the common code in it - encryption, decryptio, authentication and such. Then you subclass that to give you the final application module. He postualted that this way you could in fact subclass CGI::A once to provide an App module and an instantiation CGI for user access and a separate module and instantiation for admins. In my case, as I have users, service providers and admins I can do it three times and have three totally controllable environments for each class of access to the site.

jdtoronto

I am eager to try out the various ideas concerning subclassing an entire CGI:App. I'm doing a "lite" version of this on my project. On our web server we have a common piece of infrastructure that limits user access depending on dir location. There is a piece of my application that I want two different sets of users to have access to. So I set up this scheme:

MyApp.pm    (off somewhere outside of the document root)


  doc-root--- --------------
             |              | 
           foo_dir        bar_dir
             |              |
           foo.cgi        foo.cgi

Code for foo.cgi:
 use MyApp;
 my $webapp = MyApp->new();
 $webapp->run();
[download]

Each use the same MyApp.pm, but access to the foo_dir is limited to different users than bar_dir.

This approach has the advantage of using the existing login/ authentication scheme while allowing me to reuse my code across different locations.

One thing worth noting, is that I haven't taken advantage of CGI:Apps ability to pass in different parameters so that the same MyApp code could behave somewhat differently in these two instances.

good luck with your project.

-------------------------------------
Nothing is too wonderful to be true
-- Michael Faraday

Some would say that CGI::Application is for when you have multiple forms that are related in a linear fasion. For instance, a user registration form might have an initial form where they fill out basic information, a second form where the information is more in-depth, a third where they agree to the site's user agreement, and finally one where the complete data is submitted.

Personally, I think this can be extended into pages where the run modes share a lot of information (like database connections and templates) but the user wouldn't navigate the pages linearly. This is CGI::Application after all, and there are very few non-web applications that are so linear (outside of examples for beginning GUI programmers).

The way I look at it, I have separate run_mode's for every "page" or step in the application. Then (following your example), when mode_001 is processed/submitted, it goes to mode_002 (instead of back to mode_001) and in mode_002's run_mode method, I use ValidateRM's check_rm method, which will take care of your error handling for you and you can tell it which run_mode to return to, if there was an error.

sub mode_001 {
    my ( $self, $errs ) = @_;

    # ...
    $template->param( $errs ) if $errs;
    $template->output;    
}

sub mode_002 {
    my ( $self, $results, $err_page );

    $self = shift;
    ( $results, $err_page ) = $self->check_rm( 'mode_001',
                                '_mode001_profile' );
    return $err_page if $err_page;

    # If you've gotten this far, all the data is ok per
    # your FormValidator object

}

sub _mode001_profile {
    return {
        'required' => [ qw( email password1 password2 ) ],
        'constraints' => {
                'email' => sub { return Email::Valid->address( shift )
+; }
            },
        'msgs' => {
            'any_errors' => 'some_errors',
            'prefix' => 'err_',
            },
    };
}
[download]

Hope that helps!

Peace,

Jason

Update: It will also prefill out the previous form with the user's data when/if it returns to a previous run_mode. So if they provided their first e-mail address, but not any other stuff, then it will represent the original form with the data that the user did specify along with those 'msgs' (i.e. err_password1, err_password2) that you can incorporate into your template to color things red or whatever.

Great post, ++ to parent.

I to use ValidateRM with great success. The use use of VRM 'encouraged' me to keep each rm to just a single presentation screen, because when using VRM to process a form submission you call the orginal form presentation run mode to (re)produce the screen with errors message and data overlaid. This works best if the orginal run mode simply does presentation.

I'd like to add one useful tip. VRM requires HTML::FillInForm to repopulate the info into the presenation form. This is a very handy module for prefilling out a form in your run mode, if, for example you are doing a edit operation on something you already have in the database. A code example of filling out into a template file:

... code to setup my $t template, and get
info from the database into %fdat
would be here ...

   my $html = $t->output;
   if ( %fdat ) {
      my $fif = new HTML::FillInForm;
      $html = $fif->fill(scalarref  => \$html,
                          fdat   =>  \%fdat );
   }

   return $html;  # this is the filled-out HTML file
[download]

-------------------------------------
Nothing is too wonderful to be true
-- Michael Faraday

freddo411

I was a little confused when I read your post at first. But I coded up an example based on the docs for CGI::Application::ValidateRM, it worked perfectly. But I kept wonderiong where your reerence to HTML::FillInForm came from.

Then it dawned on me! You were saying that CGI::Application::ValidateRM uses HTML::FillInForm internally - and pointed out with your example that I could use HTML::FilInForm for filling in retrieved data or defauilts in a form.

Thanks for the pointer. I suspect I am going to modify my exisiting templates and use HTML::FillInForm rather than CGI::FormBuilder.

jdtoronto

Thank you,

I had printed out the docs and have them in front of me but hadn't really looked at them. TIme to do some more reading I think, before the project gets too far along and I can't change things.

[jdtoronto}

First off, I would encourage you to join the CGI-App mailing list. Send email to:

cgiapp-subscribe@lists.erlbaum.net

We've frequently discussed the philosophy of what should be a run-mode.

To the heart of the matter: I think you have to adjust your architecture a bit. Based only on the fact that you're looking at a 200 run-mode app, I feel you have got way too much going on. As a point of reference, my typical CGI-App has about 5-10 run-modes.

Two changes I would recommend:

1. Simplify your run-mode configuration -- roughly one mode per screen.
2. Separate functionality into multiple applications -- e.g., what you're now calling "run-modes" ("mode_001") becomes its own CGI::Application module ("UserRegistration.pm").

TTYL,

-Jesse-