aristotle laid some criticism on CGI::Prototype based on heavy usage of it. Let's take his second criticism:

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.

Now we can read Randal's feelings on this topic: Although the name CGI::Prototype implies a CGI protocol, I see no reason that this would not work with Apache::Registry in a mod_perl environment, or a direct content handler such as:

  package My::App;
  use base CGI::Prototype;
  sub handler {
    __PACKAGE__->activate;
  }
[download]

Note that the $r request object will have to be created if needed if you use this approach.

yes but..

Even with that being the case, it is clear that artistotle's concerns about request data being stored in package variables is accurate. First you create an 'object' out of the package:

our $_mirror = __PACKAGE__->reflect; # for slots that aren't subs
[download]

and then you setup the CGI instance in the 'object':

sub initialize_CGI {
  my $self = shift;
  $self->reflect->addSlot
    ([qw(CGI FIELD autoload)] => sub {
       require CGI;
       CGI::_reset_globals();
       CGI->new;
     });
}
[download]

but the 'object' is in fact a package variable, which makes mod_perl usage subject to variable stomping...

So we see that aristotle hit the nail on the head. And even though CGI::Prototype is wonderful for CGI, it needs some serious revamping for use in a mod_perl environment.

can you have it all?

Is there really a way to write an app once and have it port to any dynamic web environment? Not only that, but perform optimally in each? To reduce memory and compile-time in CGI environments and then to increase response time and pre-compile in mod_perl? And what about lighttpd? fastcgi?