In order to do that, we need to look at what Maypole's actually doing.
-As mentioned, Maypole is XXX
-
-=head2 The model class
-
-=head2 The view class
+As mentioned, Maypole is responsible for turning a URL into an object, a
+method call, and some templated output. Here's a handy diagram to
+explain how it does that:
+
+=for html
+<IMG SRC="maypole_process2.png">
+
+Maypole's process revolves around the concept of the Maypole request
+object. This is a little like Apache's request object, but at a much
+higher level - in fact, in C<mod_perl>-based Maypole front-ends, the
+Apache request object is incorporated in the Maypole request object. All
+that Maypole does is gradually flesh out this object until it contains
+something in the C<output> member, and then it is dispatched back to the
+front-end for output.
+
+So to start with, we take the Apache request (or CGI object, or other
+way of isolating what's going on) and break it down. For instance, we
+turn the URL C</beer/view/1> into
+
+ {
+ table => "beer",
+ action => "view",
+ args => [ 1 ]
+ }
+
+Then Maypole will check that C<beer> is a real table, and find the class
+that models it. It also checks whether or not we're allowed to call the
+C<view> method over the network:
+
+ {
+ table => "beer",
+ action => "view",
+ args => [ 1 ],
+ model_class => "BeerDB::Beer"
+ }
+
+Then there's a user-defined authentication method, which by default just
+lets us do anything. Now we hand over to the model class, which loads up
+the object, and decides what template we want to use:
+
+ {
+ table => "beer",
+ action => "view",
+ args => [ ],
+ objects => [ BeerDB::Beer->retrieve(1) ],
+ model_class => "BeerDB::Beer",
+ template => "view"
+ }
+
+Then it calls C<BeerDB::Beer-E<gt>view>, passing in the request object
+as a parameter, and passes the whole lot to the view class for templating.
+In the next two chapters, we'll look at how Maypole's default model and
+view classes generally do what you want them to do.