Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery

OO CGI Engine

by billyak (Friar)
on Jan 02, 2002 at 22:30 UTC ( [id://135747]=perlquestion: print w/replies, xml ) Need Help??

billyak has asked for the wisdom of the Perl Monks concerning the following question:

I've been developing some small web/cgi apps in Perl for about two years now. I am now planning on taking a rather large project that deals heavily with DBI and forms. Having never truly written a CGI based OO application, (and after much debate), I have decided to post here.

I'm pretty comfortable with using OO for data storage and retrieval, but it is the actual operation of the system that is in question. Ideally, I would want an engine: a robust, expandable beast that serves as the center of all operation for this site. My problem is that I have never done anything like this before, and have little to no idea where to start.

My original idea had quasi-hooks. When a module was requested, it added latches to a hash that went through a series of loops and ifs, launching subroutines depending on the hook and CGI parameter contents. My original implementation of this worked in my test applications, but it is becoming more and more apparent that it won't last long. I need a more robust solution, and I'm afraid I am completely inexperienced in OO engines and operation. (I did some searching here and didn't find anything too useful. I tried downloading the everything engine to peek at its source but the site was down.)

I would really appreciate any insight, design tips, things to look out for, or anything else that might be of use.


Replies are listed 'Best First'.
Re: OO CGI Engine
by Hero Zzyzzx (Curate) on Jan 02, 2002 at 22:59 UTC

    I suggest you look at CGI::Application. It sounds like it will do exactly what you're looking for, and helps you create very manageable, usable apps without getting in the way. I love it! I use it extensively in apps that work similarly to what you're describing, and I can't imagine building web applications without it and HTML::Template.

    You might also check out OpenInteract by lachoy, it appears to be a very robust application framework with a good security model.

    -Any sufficiently advanced technology is
    indistinguishable from doubletalk.

Re: OO CGI Engine
by khkramer (Scribe) on Jan 03, 2002 at 00:29 UTC

    I would suggest thinking about moving away from CGI for a large project. There are a number of good "templating" tools that allow you to divide a web application up into sets of "components", each of which can contain HTML, Perl or both.

    Our business is building very large web systems, and we use HTML::Mason on every project. Mason is stable, clean and has a number of nice features such as the ability to selectively/flexibly cache components/pages. But most importantly, using Mason doesn't limit your ability to write as much complex Perl code as you want. Anything you can do in a standalone program, you can do in a Mason component. And you can (and should) abstract out core logic into app-specific modules and 'use' them from your various Mason pieces. For big projects, this "embedded perl" approach almost always ends up being a much more efficient way to do development than the "shortcut-to-HTML" approach that CGI relies on.

    As far as "engines" go, you might want to look at the platform we developed over the course of the last couple of years: XML::Comma. Comma allows you to model all of the bits and pieces of "information" that your app uses as "documents," which can then be manipulated, stored in the filesystem, broken apart and stored in databases, transferred across the network, etc through a single API. If you tend to design applications using "quasi-hooks" and run-time dispatching, you'll probably love Comma. Most every part of the "life-cycle" of a Comma doc is hookable.

    We started out two years ago to build a temporary, XML+Perl platform that we could use until the various critical XML specs came together. At some point, we realized that even when XSLT and friends become fully usable, we'll still need a more job-specific framework for the kind of work we do. So we've continued to rewrite/develop/extend that original platform. Last month, I finally finished a complete programmer's guide to Comma, and now we're looking forward to seeing whether this stuff is as useful to other folks as it is to us.

    Having made a plug for the code I work on every day, I would like to say that every project is different, and every developer is too. You might also want to take a look at OpenInteract and AxKit. TMTOWTDI.

Re: OO CGI Engine
by dmmiller2k (Chaplain) on Jan 02, 2002 at 23:27 UTC

    I have had a great deal of success building web apps by subclassing CGI::Application (which uses HTML::Template). It is especially useful since it provides a single jumping off point for all of your applications level code.

    I would not attempt building any application more complex than a single form without it.


    You can give a man a fish and feed him for a day ...
    Or, you can
    teach him to fish and feed him for a lifetime
Re: OO CGI Engine
by lachoy (Parson) on Jan 03, 2002 at 01:18 UTC

    CGI/Mod Perl Application Design philosophy - which way do we go? is a pretty good thread about this kind of thing. I'd normally recommend OpenInteract (as some other kind folks have mentioned), but it does not currently run under a CGI environment, just mod_perl. CGI/standalone/POE/... is in the future, but not yet.

    I don't think anyone else has mentioned it yet, but OpenFrame is pretty nifty and IIRC runs under CGI no problem.

    M-x auto-bs-mode

Re: OO CGI Engine
by swiftone (Curate) on Jan 02, 2002 at 23:45 UTC
    Note that CGI::Application doesn't require HTML::Template (except perhaps for installation). I, and quite a few others, use it quite happily with Template-Toolkit (alt), and it can be used with many other templating systems since it doesn't fiddle with content, just flow control.

    My preferred method is to create a sub-class of CGI::Application that includes anything site-wide I want to use. My application modules are then subclasses of this class. (It makes more sense when you read the CGI::App docs)

by Anonymous Monk on Jan 03, 2002 at 02:10 UTC
    Take a look at Chris Winter's OpenInteract :

    It's exactly what you describe -> it takes Perl OO to another level, and has a lot of well-thought-out abstractions for security and persistence.

    I've implemented a very small site in it and learned a lot.

Re: OO CGI Engine
by Stegalex (Chaplain) on Jan 03, 2002 at 21:32 UTC
    I would like to second the suggestion that you move away from CGI and get mod_perl installed on your machine. What I have had a great deal of luck using under mod_perl is HTML::Embperl by Gerald Richter. The free tech support he offers on his site is excellent.

    Also, there is another module by GR called DBI::Recordset that encapsulates database IO in object methods. I must admit that I don't use it, but I have heard good feedback about it.

    General advice on the topic of rolling your own OO CGI engine is that it probably makes more sense to conduct more research into existing modules before taking on the task of building your own. I am not saying that there is no justification for building your own, just that I can't envision doing this myself. I am too lazy and I like chicken.

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://135747]
Approved by root
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others browsing the Monastery: (3)
As of 2024-07-14 18:01 GMT
Find Nodes?
    Voting Booth?

    No recent polls found

    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.