Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Aristotle (5147)


Blah blah blah blah blah []

Journal of Aristotle (5147)

Sunday October 14, 2007
08:20 AM

Why I would not pick CGI::Prototype again

[ #34674 ]

I started with CGI::Prototype on a project I still develop. I loved it at the time, but I have been looking to move away from it for a while. Back then it was the right choice: Catalyst wasn’t very well known nor very good yet, Jifty didn’t even exist, and even CGI::Application didn’t have ::Dispatch.

But CGIP just does too little and what it does do is mostly useless. Overall, it is is very stargate oriented.

  • Its core idea is the “stay on this page or go to another?” mechanism. This is directly in opposition to POST-redirect-GET – and therefore to good HTTP style. I didn’t have to fight CGIP to do things properly, but I had to ignore its offerings and manually devise everything I needed.

  • It is strongly targetted at classic process-per-request CGI environments. It tries to avoid compiling too much by implicitly require-ing subclasses in the dispatcher, and stores request-specific data in slots of the main object, which are effectively global variables.

  • Because the dispatcher plays double duty as an on-demand code loader, it’s hard to make it do URI-based dispatching sensibly. I’ve had to reinvent lots of the dispatching infrastructure that any more comprehensive framework would have given me for free, and my code is still less flexible than the routing provided by every other framework.

  • It treats the output – both the response headers and the body – as a single thing. That means you have to generate all output at once, or else you have to reinvent the mechanisms other frameworks provide to independently set headers and produce the response body – and indeed I ended up doing the latter.

  • It does nothing to help you decouple concerns. Normally, no variables are passed to your templates except self, whereby your templates call back into the application. This turned out to be a very bad idea. What should have been there is a mechanism like the stash in Catalyst, which lets you prepare data piecemeal in the controller, which is finally passed to the template. This too – you guessed it – I had to write myself.

Overall, between ignoring its suggested ways of doing things, overriding its defaults, and writing infrastructure myself, I basically wrote my own web framework on top of the tiniest bits of CGIP.

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • CGIP is deliberately very thin. It is a framework which abstracts away the most boring parts of every web app I've ever written. It's true that if CGIP::Hidden doesn't do what you want, you're left with only the thin framework above it. One of my long-term todo tasks was to make that a bit more pluggable, to handle the style that better suits REST-ful APIs in addition to hidden-field state passing, but none of my clients had that as a problem, so I didn't add it yet. :)

    Your comment about data-push vs

    • Randal L. Schwartz
    • Stonehenge
  • You don't have to like CGIP, and that's fine. This sounds like it might be in response to my last journal post. I wasn't trying to push CGIP on anyone, and really did mean it when I said that anyone who tells you what to use before they know your problem isn't worth listening to. I've recommended Catalyst to plenty of our clients, and usually do so first, saying "If this doesn't work for you, then we'll talk about CGIP". It certainly isn't something I recommend people start with if something else works bett
    • It started as a reply to your post, yes. Then I realised it was beside the issue. Anyway, it is why I wouldn’t pick CGIP again.

      It’s not like URIs are magic.

      They’re not, but CGIP scatters the responsibility for dispatch across all of your classes by way of the respond method, and it will not invoke a method other than respond in the course of dispatch, nor does it provide a built-in mechanism of passing parameters to it. So you have to rig up the entire machinery to parse the URI and r

      • I'm not sure what you were doing with CGIP and URL dispatch, but I never had to scatter them across anything. It sounds like you were doing something the hard way.