package Apache::MVC;
-use base 'Maypole';
-use Apache;
-use Apache::Request;
+
+our $VERSION = '2.10';
+
use strict;
use warnings;
-our $VERSION = "0.3";
-sub get_request {
- shift->{ar} = Apache::Request->new(Apache->request);
-}
+use base 'Maypole';
+use Maypole::Headers;
+use Maypole::Constants;
+
+__PACKAGE__->mk_accessors( qw( ar ) );
+
+BEGIN {
+ my $version;
+ eval 'use mod_perl2; $version = $mod_perl2::VERSION; ';
+ if ($@) {
+ use mod_perl;
+ $version = 0;
+ require Apache;
+ require Apache::Request;
+ } else {
+ require Apache2::RequestIO;
+ require Apache2::RequestRec;
+ require Apache2::RequestUtil;
+ require APR::URI;
+ require Apache2::Request;
+ }
-sub parse_location {
- my $self = shift;
- $self->{path} = $self->{ar}->uri;
- my $loc = $self->{ar}->location;
- $self->{path} =~ s/^$loc//; # I shouldn't need to do this?
- $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;
-
- $self->{params} = { $self->{ar}->content };
- $self->{query} = { $self->{ar}->args };
+ use constant APACHE2 => $version;
}
-1;
-
=head1 NAME
-Apache::MVC - Web front end to a data source
+Apache::MVC - Apache front-end to Maypole
=head1 SYNOPSIS
package BeerDB;
- use base 'Apache::MVC';
- sub handler { Apache::MVC::handler("BeerDB", @_) }
- BeerDB->set_database("dbi:mysql:beerdb");
- BeerDB->config->{uri_base} = "http://your.site/";
- BeerDB->config->{display_tables} = [qw[beer brewery pub style]];
- # Now set up your database:
- # has-a relationships
- # untaint columns
-
- 1;
+ use Maypole::Application;
=head1 DESCRIPTION
-A large number of web programming tasks follow the same sort of pattern:
-we have some data in a datasource, typically a relational database. We
-have a bunch of templates provided by web designers. We have a number of
-things we want to be able to do with the database - create, add, edit,
-delete records, view records, run searches, and so on. We have a web
-server which provides input from the user about what to do. Something in
-the middle takes the input, grabs the relevant rows from the database,
-performs the action, constructs a page, and spits it out.
-
-This module aims to be the most generic and extensible "something in the
-middle".
-
-An example would help explain this best. You need to add a product
-catalogue to a company's web site. Users need to list the products in
-various categories, view a page on each product with its photo and
-pricing information and so on, and there needs to be a back-end where
-sales staff can add new lines, change prices, and delete out of date
-records. So, you set up the database, provide some default templates
-for the designers to customize, and then write an Apache handler like
-this:
-
- package ProductDatabase;
- use base 'Apache::MVC';
- __PACKAGE__->set_database("dbi:mysql:products");
- BeerDB->config->{uri_base} = "http://your.site/catalogue/";
- ProductDatabase::Product->has_a("category" => ProductDatabase::Category);
- # ...
-
- sub authenticate {
- my ($self, $request) = @_;
- return OK if $request->{ar}->get_remote_host() eq "sales.yourcorp.com";
- return OK if $request->{action} =~ /^(view|list)$/;
- return DECLINED;
- }
- 1;
+A mod_perl platform driver for Maypole. Your application can inherit from
+Apache::MVC directly, but it is recommended that you use
+L<Maypole::Application>.
-You then put the following in your Apache config:
+=head1 INSTALLATION
- <Location /catalogue>
+Create a driver module like the one illustrated in L<Maypole::Application>.
+
+Put the following in your Apache config:
+
+ <Location /beer>
SetHandler perl-script
- PerlHandler ProductDatabase
+ PerlHandler BeerDB
</Location>
-And copy the templates found in F<templates/factory> into the
-F<catalogue/factory> directory off the web root. When the designers get
-back to you with custom templates, they are to go in
-F<catalogue/custom>. If you need to do override templates on a
-database-table-by-table basis, put the new template in
-F<catalogue/I<table>>.
+Copy the templates found in F<templates/factory> into the F<beer/factory>
+directory off the web root. When the designers get back to you with custom
+templates, they are to go in F<beer/custom>. If you need to override templates
+on a database-table-by-table basis, put the new template in F<beer/I<table>>.
+
+This will automatically give you C<add>, C<edit>, C<list>, C<view> and C<delete>
+commands; for instance, to see a list of breweries, go to
+
+ http://your.site/beer/brewery/list
+
+For more information about how the system works and how to extend it,
+see L<Maypole>.
+
+=head1 Implementation
+
+This class overrides a set of methods in the base Maypole class to provide its
+functionality. See L<Maypole> for these:
+
+=over
+
+=item get_request
+
+=cut
+
+sub get_request {
+ my ($self, $r) = @_;
+ my $ar = (APACHE2) ? Apache2::Request->new($r) : Apache::Request->new($r);
+ $self->ar($ar);
+}
+
+=item parse_location
+
+=cut
+
+sub parse_location {
+ my $self = shift;
+
+ # Reconstruct the request headers
+ $self->headers_in(Maypole::Headers->new);
+ my %headers;
+ if (APACHE2) { %headers = %{$self->ar->headers_in};
+ } else { %headers = $self->ar->headers_in; }
+ for (keys %headers) {
+ $self->headers_in->set($_, $headers{$_});
+ }
+ my $path = $self->ar->uri;
+ my $loc = $self->ar->location;
+ {
+ no warnings 'uninitialized';
+ $path .= '/' if $path eq $loc;
+ $path =~ s/^($loc)?\///;
+ }
+ $self->path($path);
+
+ $self->parse_path;
+ $self->parse_args;
+}
+
+=item parse_args
+
+=cut
+
+sub parse_args {
+ my $self = shift;
+ $self->params( { $self->_mod_perl_args( $self->ar ) } );
+ $self->query( $self->params );
+}
+
+=item redirect_request
+
+=cut
+
+# FIXME: use headers_in to gather host and other information?
+sub redirect_request
+{
+ my $r = shift;
+ my $redirect_url = $_[0];
+ my $status = "302";
+ if ($_[1]) {
+ my %args = @_;
+ if ($args{url}) {
+ $redirect_url = $args{url};
+ } else {
+ my $path = $args{path} || $r->path;
+ my $host = $args{domain} || $r->ar->hostname;
+ my $protocol = $args{protocol} || $r->get_protocol;
+ $redirect_url = "${protocol}://${host}/${path}";
+ }
+ $status = $args{status} if ($args{status});
+ }
-This will automatically give you C<add>, C<edit>, C<list>, C<view> and
-C<delete> commands; for instance, a product list, go to
+ $r->headers_out->set('Status' => $status);
+ $r->headers_out->set('Location' => $redirect_url);
+ return OK;
+}
- http://your.site/catalogue/product/list
+=item get_protocol
-For a full example, see the included "beer database" application.
+=cut
-=head1 HOW IT WORKS
+sub get_protocol {
+ my $self = shift;
+ my $protocol = ( $self->ar->protocol =~ m/https/i ) ? 'https' : 'http' ;
+ return $protocol;
+}
-There's some documentation for the workflow in L<Apache::MVC::Workflow>,
-but the basic idea is that a URL part like C<product/list> gets
-translated into a call to C<ProductDatabase::Product-E<gt>list>. This
-propagates the request with a set of objects from the database, and then
-calls the C<list> template; first, a C<product/list> template if it
-exists, then the C<custom/list> and finally C<factory/list>.
+=item send_output
-If there's another action you want the system to do, you need to either
-subclass the model class, and configure your class slightly differently:
+=cut
- package ProductDatabase::Model;
- use base 'Apache::MVC::Model::CDBI';
+sub send_output {
+ my $r = shift;
+ $r->ar->content_type(
+ $r->content_type =~ m/^text/
+ ? $r->content_type . "; charset=" . $r->document_encoding
+ : $r->content_type
+ );
+ $r->ar->headers_out->set(
+ "Content-Length" => do { use bytes; length $r->output }
+ );
- sub supersearch :Exported {
- my ($self, $request) = @_;
- # Do stuff, get a bunch of objects back
- $r->objects(\@objects);
- $r->template("template_name");
+ foreach ($r->headers_out->field_names) {
+ next if /^Content-(Type|Length)/;
+ $r->ar->headers_out->set($_ => $r->headers_out->get($_));
}
- ProductDatabase->config->{model_class} = "ProductDatabase::Model";
+ APACHE2 || $r->ar->send_http_header;
+ $r->ar->print( $r->output );
+}
-(The C<:Exported> attribute means that the method can be called via the
-URL C</I<table>/supersearch/...>.)
+=item get_template_root
-Alternatively, you can put the method directly into the specific model
-class for the table:
+=cut
- sub ProductDatabase::Product::supersearch :Exported { ... }
+sub get_template_root {
+ my $r = shift;
+ $r->ar->document_root . "/" . $r->ar->location;
+}
-By default, the view class uses Template Toolkit as the template
-processor, and the model class uses C<Class::DBI>; it may help you to be
-familiar with these modules before going much further with this,
-although I expect there to be other subclasses for other templating
-systems and database abstraction layers as time goes on. The article at
-C<http://www.perl.com/pub/a/2003/07/15/nocode.html> is a great
-introduction to the process we're trying to automate.
+sub _mod_perl_args {
+ my ( $self, $apr ) = @_;
+ my %args;
+ foreach my $key ( $apr->param ) {
+ my @values = $apr->param($key);
+ $args{$key} = @values == 1 ? $values[0] : \@values;
+ }
+ return %args;
+}
+
+1;
+
+=back
=head1 AUTHOR
Simon Cozens, C<simon@cpan.org>
+Marcus Ramberg, C<marcus@thefeed.no>
+Sebastian Riedel, C<sri@oook.de>
=head1 LICENSE
You may distribute this code under the same terms as Perl itself.
+
+=cut
projects / maypole.git / blobdiff