I do not write applications very often, so I don't want to fill my head with the stuff needed to master a powerful "framework". CGI::Prototype::Hidden is small enough, and it is very easy to borrow from one application to another.
I love it because it allows me to create apps in my preferred sequence. Templates first: I want to define how I want to *use* the application. A pencil and a piece of paper are sufficient to draw the workflows between the templates. Test cases next: The starting screen (template) defines the params, the _state param defines the module, the "target screen" the expected output. Just use CGI.pm's command line capability and capture STDOUT. Then the modules, with appropriate returns for their target screens.
The POD sucks, compared to the Linux Mag article. Having to jump up and down the class inheritances is always annoying, but in this case it can be really misleading. Recommended practice in CGIP (like overriding render_enter) are actually a very bad idea in CGIPH.
I started with CGI::Prototype on a project I still develop. I would not pick it again. 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.
[This review was also posted on my use.Perl journal.  See there for discussion.]
Documentation: The documentation needs to grow a bit. It would be helpful if more examples were given. For comparison, the CGI::Application documentation is very in depth on how to use the framework.
Other: I have read in the newsgroup about it being extended to create a plugin mechanism and to hook into prototype.js for AJAX support. I think those two things would make C::P rock. I look forward to their addition and being able to contribute plugins myself.
You can find a tutorial split in 3 parts in the May-Jul 2005 issues of Linux magazine, the July issue is not out yet of course, but I am looking forward to it.
Though, I have used CGI::Application for years and I think it's a pretty good framework... If you are going to make a review, evaluate the merits of the software at hand, anything else is not really helpful.