Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked

Re: Yet another "why CGI-Application" question

by weierophinney (Pilgrim)
on Nov 29, 2004 at 15:17 UTC ( #410943=note: print w/replies, xml ) Need Help??

in reply to Yet another "why CGI-Application" question

First off, to really start using CGI::Application, you will need to understand at least some rudiments of perl OOP. The first time I looked at it, I didn't understand perl OOP at all, and I quickly dismissed it. However, once I'd grasped the fundamentals of perl OOP, I went back and looked at it and liked it much more. Contrary to what merlyn says, I don't find the guts of it to be monolithic; in fact, I was shocked to discover how lean it actually is, considering what all it lets you do.

To address some of your specific issues:

  • One script for one run mode is asking for trouble when the run modes are all linked by a common theme. What CGI::App does is have you group run modes -- so that all operations relevant to a process are in one place. However, you don't necessarily need all these run modes in the same file; that's why namespaces are so much fun -- simply load up the appropriate file with the run mode you're requesting when you need it, or load them all up when the initial module is loaded.

    The beauty of doing it like this is that if you group the application code, you know where all of it is. Additionally, using the dispatch table provided by CGI::Application, and which you setup in your class, it becomes very easy to determine what method is invoked at each point in the application -- making debugging very easy. Look up the run mode, then find the method... you're there.
  • If you want to build reusable applications, CGI::App is your friend. Build an application module once, and use it many times. You can customize your application using metadata passed via the instance script (such as template location, DBI parameters, etc).
  • You don't have to use; you can override the query() method to have it pull in CGI::Simple or some other module that gives you access to CGI parameters. For that matter, you aren't tied to HTML::Template, either; you can use any templating system you want (or none at all), simply by overriding the appropriate method(s).

    This kind of flexibility is one of the key strengths of CGI::Application, in my opinion.
  • If you have multiple applications, but you want them to share some common parameters -- templates, session handling, etc. -- again, CGI::Application is your friend. Build a superclass for your site that performs these actions or sets up your environment, and have all the various application modules inherit from it.

Again, you need to have a basic understanding of how OOP works in perl, but once you do, CGI::Application becomes a breeze to utilize, and an incredibly flexible tool. It's not the be-all, end-all of web programming, but it provides a nice, lightweight framework for developing web applications.

  • Comment on Re: Yet another "why CGI-Application" question

Log In?

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

How do I use this? | Other CB clients
Other Users?
Others scrutinizing the Monastery: (7)
As of 2020-12-04 08:59 GMT
Find Nodes?
    Voting Booth?
    How often do you use taint mode?

    Results (58 votes). Check out past polls.