]> git.decadent.org.uk Git - maypole.git/commitdiff
Can't be arsed to do any more for now.
authorSimon Cozens <simon@simon-cozens.org>
Wed, 10 Mar 2004 13:53:25 +0000 (13:53 +0000)
committerSimon Cozens <simon@simon-cozens.org>
Wed, 10 Mar 2004 13:53:25 +0000 (13:53 +0000)
git-svn-id: http://svn.maypole.perl.org/Maypole/trunk@83 48953598-375a-da11-a14b-00016c27c3ee

doc/StandardTemplates.pod

index c3c4dd31db76a5257bb63e48567a445ad8e0f94b..215c4ca1f4de24f22564f7a422696d44c309651d 100644 (file)
@@ -193,16 +193,55 @@ Notice that this does use hard-coded names for the templates to go to next.
 Feel free to override this in your subclasses:
 
     sub do_edit :Exported {
-        my ($class, $r) = shift;
+        my ($class, $r) = @_;
         $class->SUPER::do_edit($r);
         $r->template("my_edit");
     }
 
 =head3 delete
 
+The delete method takes a number of arguments and deletes those rows from the
+database; it then loads up all rows and heads to the F<list> template.
+You almost certainly want to override this to provide some kind of
+authentication.
 
 =head3 list
 
+Listing, like viewing, is a matter of selecting objects for
+presentation. This time, instead of a single object specified in the
+URL, we want, by default, all the records in the table:
+
+    sub list :Exported {
+        my ($class, $r) = @_;
+        $r->objects([ $self->retrieve_all ])
+    }
+
+However, things are slightly complicated by paging and ordering by
+column; the default implementation also provides a C<Class::DBI::Pager>
+object to the templates and uses that to retrieve the appropriate bit of
+the data, as specified by the C<page> URL query parameter. See the F<pager> 
+template below.
+
 =head3 search
 
+Searching also uses paging, and creates a query from the C<POST>
+parameters. It uses the F<list> template to display the objects once
+they've been selected from the database.
+
 =head2 The templates and macros
+
+Once these actions have done their work, they hand a set of objects to
+the templates; if you haven't specified your own custom template
+globally or for a given class, you'll be using the factory specified
+template. Let's take a look now at each of these and how they're put
+together.
+
+The beauty of the factory specified templates is that they make use of
+the classes' metadata as supplied by the view class. Although you're
+strongly encouraged to write your own templates, in which you don't need
+to necessarily be as generic, the factory templates will always do the
+right thing for any class without further modification.
+
+=head3 F<view> 
+=head3 F<edit>
+=head3 F<list>