[Maypole] Maypole comparisons/competitors

[Dave Ranney]

Simon,

 From the Wiki:

"
CGI::Application

Not a competitor, a collaborator. I have no problems envisioning a 
CGI::Application::Maypole, and indeed I'd like to see one.
"

I'd very much like to have a CGI-based driver for Maypole, to sit 
alongside Apache::MVC. In fact, I started to investigate what it would 
take to put one together, but got stopped cold by Maypole.pm's reliance 
on Apache::Constants. That module just won't play well outside of 
mod_perl (right? Or am I missing something?).

I'm pretty sure that a CGI-based subclass of Maypole would require that 
Maypole be decoupled from Apache::Constants and the mod_perl paradigm 
in general. Looking at the code in Maypole.pm, I see that the various 
constants are really only used as result codes from various subroutines 
(is_applicable(), authenticate()). handler() also returns one of the 
Apache constants, but only because that is what the default view class 
(Maypole::View::TT) returns (and of course under mod_perl, handler() 
*must* return a valid result code). handler() could just as easily 
return any other value (i.e. whatever the current View class returns).

Once Apache::Constants is out of the way, it should be a simple matter 
to subclass Maypole (CGI::MVC?), overriding get_request() and 
parse_location(). Next step would be to create a new View class that 
understands CGI objects rather than Apache::Request objects. Shouldn't 
be too hard.

I'm pretty sure that at that point, you'd be able to take BeerDB.pm, 
change it to be a subclass of "CGI::MVC" rather than Apache::MVC, and 
then simply write your CGI script like this:

#!/usr/bin/perl
use BeerDB;
BeerDB->handler();
exit;

So, am I off base? Is it feasible to remove Maypole's reliance on 
mod_perl code?

Thanks,

-Dave