Beefy Boxes and Bandwidth Generously Provided by pair Networks
Don't ask to ask, just ask
 
PerlMonks  

Re: Re: Scaling single-script CGI applications

by Hero Zzyzzx (Curate)
on Jul 09, 2001 at 05:00 UTC ( [id://94879]=note: print w/replies, xml ) Need Help??


in reply to Re: Scaling single-script CGI applications
in thread Scaling single-script CGI applications

Your points are good, but I think you're focusing on the idea of "one module is the application" related to CGI::Application too much.

The way I use CGI::Application is I write a central module, "SuperClass.pm" that has shared functions for all my other modules that make up an entire web application. I then use this SuperClass in all my application modules.

Example:
Here's SuperClass, the shared base class for all my modules.

Package SuperClass.pm use DBI; use whatever_else_you_want; use base 'CGI::Application'; sub cgiapp_init{ my $self=shift; ## initialize variables, stuff them into params to allow ## all other modules to inherit common functions. For ## instance, I'll set up my DBI connection, user ## authentication, HTML::Template object, etc. all in ## here. Then every object from here on down can access ## them. }

Here's an application module, UserManager.pm, which inherits many of it's functions from SuperClass.:
package UserManager; use base 'SuperClass'; sub setup{ my $self=shift; my $q = $self->query(); #Get CGI.pm object $self->start_mode('print'); $self->mode_param('rm'); $self->run_modes( 'login'=>'login', 'delete'=>'delete', 'list'=>'list' #More run modes here. ); } sub login{ #do stuff here according to what's inherited from #SuperClass- For instance, use the HTML::Template #that SuperClass specifies. This greatly increases #reusability. }

I then build all my other application modules split logically into appropriately named .pms', but all still sharing the same core. e.g. there's a UserManager.pm, Survey.pm, RSS.pm, Search.pm, etc.

I don't think of developing with CGI::Application like I need to stuff everything into one module at all, put your shared functions into a "SuperClass" and then use that as the API that you develop the rest of your application modules around.

Though I'm pretty much a "lone-wolfer," this methodology seems to lend itself very nicely to working with a team: You articulate to them what is provided by SuperClass, and they code around it. If you need to figure out what someone wrote, you just look at their run modes and you can very easily figure out what's happening. Seems pretty scalable to me.

Hope this helps! I really suggest that anyone looking to make webapps look closely at CGI::Application. It enforces good coding standards, uses the excellent HTML::Template module to great effect, and is very flexible and lightweight.

Replies are listed 'Best First'.
Re: Re: Re: Scaling single-script CGI applications
by voyager (Friar) on Jul 09, 2001 at 06:36 UTC
    It sounds like we are largely in agreement. And I'm not the one " ...focusing on the idea of 'one module is the application' related to CGI::Application too much. "

    From the Abstract of CGI::Application's documentation:

    The guiding philosophy behind CGI::Application is that a web-based application can be organized into a specific set of ``Run-Modes.'' Each Run-Mode is roughly analogous to a single screen (a form, some output, etc.). All the Run-Modes are managed by a single ``Application Module'' which is a Perl module.
    Since the subject of the node is "Scaling single-script CGI applications" (my emphasis) I thought it important to point out that the single-module approach is not the way to go. But we agree on that, right? :)

      Yes. Sorry I didn't articulate it very clearly, but what I was getting at is that you can create a central repository of shared stuff, and then split out your major functions into different modules, not a single script application. CGI::Application makes this very easy, and this functionality is very well thought out by the author, Jesse Erlbaum.

      If you were thinking of starting an application as a single script, with the idea that you may split it out later, CGI::Application would be a good way to start.

      When you were ready to split your single script app up, you'd put your setup() or cgi_appinit() subs into your shared SuperClass and your other modules could run pretty much untouched.

      This might be a good way to go: Develop with CGI::Application for all it provides for a single script app, AND because it'll set you up better down the road as you need to bump up your script's functionality.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://94879]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others exploiting the Monastery: (5)
As of 2024-03-19 05:31 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found