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.

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.

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