Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl Monk, Perl Meditation

super CGI?

by stonecolddevin (Vicar)
on Apr 17, 2006 at 17:39 UTC ( #543878=perlquestion: print w/replies, xml ) Need Help??
stonecolddevin has asked for the wisdom of the Perl Monks concerning the following question:

hey gang,

Allow me to start by apologizing for a lack of research, but this just came to me:

Wouldn't it be nice to have a sort of super-CGI class that incorporates form validation, email validation, session management, DB interface, HTML templating, etc?

Perhaps this isn't well thought through, and maybe there's a reason it's not already been done, but I think it would be VERY nice to have one object from which you can do basically anything in your code with...

Some obvious drawbacks may perhaps be speed, organization, and/or security, but with the current modules out there, all one would REALLY need to do is just tie them together...

CGI::Application does this to an extent, however you must use all the plugin modules, which is something i'd like to get away from.

Does this sound somewhat reasonable?


Replies are listed 'Best First'.
Re: super CGI?
by TedYoung (Deacon) on Apr 17, 2006 at 17:54 UTC

    I have used and researched many different web frameworks over my years as a web app developer. I have found that the general "try to do everything" frameworks are often not very good, because they try to be too general.

    Some examples are Enterprise Java Beans (sorry to not use a Perl example, that is coming shortly). They try to do everying, but because they are so flexible, the developer ends up doing way too much extra work.

    Then there are frameworks that focus on a particular type of application. For example, java struts work well for designing strut-stype applications. EZ publish (a PHP kit) works well for news sites.

    So, what is happening is that it is very difficult to make something that works for all jobs. The more specific your target, the better job you can do designing a solution. This is true for app frameworks.

    For that reason, I like to plug together a set of different tools to meet my needs on a per-job basis. For example, in one application, I might use Class:DBI as my database interface and Template Toolkit as my view generator. But another job might be easier to develop if I used DBI as the database interface.

    Now, moving more specifically to your example: how do you validate a form, or an email? How do you manage a session? It changes from one category of application to another.

    While it may take a little extra work glueing your components (APIs) together, the trade-off in flexibility is worth it (for the kinds of apps I deal with).

    In short, it is very hard to put something monolithic together that will serve many jobs. Of course, by my very own assertions, it is quite possible that you can put together a framework that meets the needs of the types of apps you develop very well.

    Ted Young

    ($$<<$$=>$$<=>$$<=$$>>$$) always returns 1. :-)
Re: super CGI?
by sgifford (Prior) on Apr 17, 2006 at 17:54 UTC
    I like that I can pick and choose exactly which CGI module, database module, templating module, etc. I use; it lets me select components tailored to the application's design and to my personal preferences. One of my favorite things about Perl is how it can connect all of these different components in so many different ways. I don't find it that troublesome to hook the different modules together, though there are definitely some things that could be made easier.
      I really *hate* choosing all that stuff. I use, Class::DBI and Template because it seems these are the consensus favorites (I have zero statistical evidence).

      One of *my* favorite things about Perl is the massive number of modules on CPAN. This is why I try and pick the most popular Web app components -- they are more likely to have cool plugins/extensions/subclasses of their own.

      I have checked out Catalyst but, for my tastes, it has too many options, allowing me to choose which templating system, object-database mapper, etc, which feels to me an awful lot like "back to square one." This profliferation of options is probably why I can't get my head around the Catalyst documentation. Everything is much more complicated than it needs to be because TMTOWTDI.

      I would be thrilled if someone made some smart decisions and put together an intelligently documented Web framework. I want an opinionated "super" What a great way to put it. ++dhoss.

      Don't get me wrong -- I love that the options exist on glorious CPAN, and I respect why people prefer a custom-rolled solution or a looser framework. I just want the option of ... less options ;->

      This sounds a lot like Rails in the Ruby world, but Rails boots its own webserver and has all kinds of code generation. It would be cool to start something that runs acceptably under CGI and then if you want it faster/more custom you just move it to an established, scalable persistence system like mod_perl or fastCGI (thus avoiding some of Rails' scalability pains).

      If CGI::Application doesn't feel like the right tool, dhoss, you might check out CGI::Prototype by Randal Schwartz, which is a very cool control layer, albeit one with all sorts of Smalltalk-like hairs growing out of it. You might hate those hairs, or decide they are extremeley neat and Perl-ish in the best sense of the word. Adding methods on the fly would be an extremely useful way to extend a Web framework, and a Prototyped class gets you there.

      Some sort of mix of that, Class::DBI, Class::DBI::Loader, Template (aka Template Toolkit) and a form module like CGI::FormBuilder could be a great "super CGI" with the right amount of glue code and a light touch.

      And a text search module like Kinosearch could be a great foundation for a first plugin.

      Of course the exact mix of modules is rather inconsequential to me. I'll gladly trade DBIx::Class for CDBI or Data::FormValidator for CGI::FormBuilder or HTML::Template for Template if the framework is smooth enough.

        I really like how you worded this post. These are basically my exact sentiments.

        I'm not sure i want something as big as Catalyst, but maybe i'm wrong. I'll definitely look into trying it out, and maybe i can hack something out and add it on, and perhaps, submit it as a patch.

Re: super CGI?
by CountZero (Bishop) on Apr 17, 2006 at 18:18 UTC
    Catalyst seems to come close to what you want. It has loads of "plugins" for your CGI, DB, templating, session management, ... etc and you can "mix and match" to your heart's content. Many of these plugins are just thin wrappers around other well-established modules, so you leverage existing modules and don't have to re-invent the wheel.


    "If you have four groups working on a compiler, you'll get a 4-pass compiler." - Conway's Law

Re: super CGI?
by TedPride (Priest) on Apr 17, 2006 at 21:43 UTC
    I have very little trouble coding a "use" for every module I need, and using separate objects. What I have most trouble with is installing modules that didn't come with the standard Perl package
      I don't like having
      use Foo; use Bar; use Baz; use Quux; use Foo::Bar; ...

      I'd much rather have
      use Super::Foo; my $super_cgi = Super::Foo->new; ...
        In that case, consider writing your own meta CGI::Application module:
        package Dhoss::App; use Foo; use Bar; use Baz; use Quux; use Foo::Bar; use base 'CGI::Application'; 1;
        Then start out every app based on that super class (use base 'Dhoss::App';). Easy peasy.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://543878]
Approved by Limbic~Region
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others drinking their drinks and smoking their pipes about the Monastery: (4)
As of 2018-05-27 05:36 GMT
Find Nodes?
    Voting Booth?