Add refactored CGI::Maypole to the mix.

[maypole.git] / lib / Maypole.pm

diff --git a/lib/Maypole.pm b/lib/Maypole.pm
index 20a3c0e02f14c8593e824fdd9c59ce310a3a9320..fedd3e5af00af2e0d671cefae041f808db8f7c60 100644 (file)
--- a/lib/Maypole.pm
+++ b/lib/Maypole.pm
@@ -118,6 +118,16 @@ sub additional_data {}
 
 sub authenticate { return OK }
 
+sub parse_path {
+    my $self = shift;
+    $self->{path} ||= "frontpage";
+    my @pi = split /\//, $self->{path};
+    shift @pi while @pi and !$pi[0];
+    $self->{table} = shift @pi;
+    $self->{action} = shift @pi;
+    $self->{args} = \@pi;
+}
+
 =head1 NAME
 
 Maypole - MVC web application framework
@@ -233,7 +243,8 @@ introduction to the process we're trying to automate.
 You should probably not use Maypole directly. Maypole is an abstract
 class which does not specify how to communicate with the outside world.
 The most popular subclass of Maypole is L<Apache::MVC>, which interfaces
-the Maypole framework to Apache mod_perl.
+the Maypole framework to Apache mod_perl; another important one is
+L<CGI::Maypole>.
 
 If you are implementing Maypole subclasses, you need to provide at least
 the C<parse_location> and C<send_output> methods. You may also want to
@@ -253,6 +264,8 @@ There's more documentation, examples, and a wiki at the Maypole web site:
 
 http://maypole.simon-cozens.org/
 
+L<Apache::MVC>, L<CGI::Maypole>.
+
 =head1 AUTHOR
 
 Simon Cozens, C<simon@cpan.org>