]> git.decadent.org.uk Git - maypole.git/commitdiff
We'll call this done.
authorSimon Cozens <simon@simon-cozens.org>
Fri, 16 Apr 2004 12:32:15 +0000 (12:32 +0000)
committerSimon Cozens <simon@simon-cozens.org>
Fri, 16 Apr 2004 12:32:15 +0000 (12:32 +0000)
git-svn-id: http://svn.maypole.perl.org/Maypole/trunk@136 48953598-375a-da11-a14b-00016c27c3ee

doc/About.pod

index 074f4bc1a223810e197a26c4a5447b7c5ba4b4ed..3600a9476dcc01e3db038fd04ebff6fc3ea2c1dd 100644 (file)
@@ -257,8 +257,56 @@ of this manual will be about how to do that.
 
 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.