-=haed1 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 MyCorp::ProductDatabase;
- use base 'Apache::MVC';
- __PACKAGE__->set_database("dbi:mysql:products");
+=head1 DESCRIPTION
+
+Maypole is a Perl web application framework to Java's struts. It is
+essentially completely abstracted, and so doesn't know anything about
+how to talk to the outside world. C<Apache::MVC> is a mod_perl based
+subclass of Maypole.
+
+To use it, you need to create a package which represents your entire
+application. In our example above, this is the C<BeerDB> package.
+
+This needs to first inherit from C<Apache::MVC>, and then call setup.
+This will give your package an Apache-compatible C<handler> subroutine,
+and then pass any parameters onto the C<setup_database> method of the
+model class. The default model class for Maypole uses L<Class::DBI> to
+map a database to classes, but this can be changed by messing with the
+configuration. (B<Before> calling setup.)
+
+Next, you should configure your application through the C<config>
+method. Configuration parameters at present are:
+
+=over
+
+=item uri_base
+
+You B<must> specify this; it is the base URI of the application, which
+will be used to construct links.
+
+=item display_tables
+
+If you do not want all of the tables in the database to be accessible,
+then set this to a list of only the ones you want to display
+
+=item rows_per_page
+
+List output is paged if you set this to a positive number of rows.
+
+=back
+
+You should also set up relationships between your classes, such that,
+for instance, calling C<brewery> on a C<BeerDB::Beer> object returns an
+object representing its associated brewery.
+
+For a full example, see the included "beer database" application.
+
+=head1 INSTALLATION
+
+Create a driver module like the one above.
+
+Put the following in your Apache config:
+
+ <Location /beer>
+ SetHandler perl-script
+ PerlHandler BeerDB
+ </Location>
+
+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 do 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, 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 AUTHOR
+
+Simon Cozens, C<simon@cpan.org>
+Marcus Ramberg, C<marcus@thefeed.no>
+Screwed up by Sebastian Riedel, C<sri@oook.de>
+
+=head1 LICENSE