Re: Re: CGI::Application, have I made a big mistake.

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

Comment on Re: Re: CGI::Application, have I made a big mistake.

Replies are listed 'Best First'.
Re: Re: Re: CGI::Application, have I made a big mistake. by freddo411 (Chaplain) on Nov 25, 2003 at 18:07 UTC
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	[reply] [d/l]

Replies are listed 'Best First'.

Re: Re: Re: CGI::Application, have I made a big mistake.
by freddo411 (Chaplain) on Nov 25, 2003 at 18:07 UTC

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

[reply]
[d/l]