X-Git-Url: https://git.decadent.org.uk/gitweb/?a=blobdiff_plain;f=lib%2FApache%2FMVC%2FWorkflow.pod;h=15d87c03120d15bb6c93424870eebd9861240915;hb=5cccc5a89004f9c514e9d611b5e2a02e9aa28ece;hp=14a69300069a9531c0f760419f2cba013d266abd;hpb=fa685ce517bd35c12ed6681803d9d0d6b1793159;p=maypole.git diff --git a/lib/Apache/MVC/Workflow.pod b/lib/Apache/MVC/Workflow.pod index 14a6930..15d87c0 100644 --- a/lib/Apache/MVC/Workflow.pod +++ b/lib/Apache/MVC/Workflow.pod @@ -64,7 +64,7 @@ several slots of the request object. First, C and C should be populated with the name of the table and the action parts of the URL. Any other arguments should be placed in a listref in the C slot, and GET and POST parameters should be arranged into a hash -and placed in the C slot. +and placed in the C and C slots, respectively. Some people may not like the idea of passing everything around in the URL; this is the method to override for you. Of course, you'll also need @@ -95,7 +95,9 @@ should return an Apache status code. =head2 Add any additional data to the request The open-ended C method allows any additional fiddling -with the request object before it is despatched. +with the request object before it is despatched. Specifically, it allows +you to add to the C slot, which is a hash of arguments to +be added to the template. =head2 Ask model for widget set @@ -114,6 +116,85 @@ We will go into more detail about these last two phases. =head1 Model class processing The model's C method is usually a thin wrapper around the -action that we have selected. +action that we have selected. It sets the template name to the name of +the action, fills C with an object of that class whose ID comes +from the URL arguments if there is one. For instance, C +will do the moral equivalent of + + $r->objects([ BeerDB::Beer->retrieve(12) ]); + +Then it calls the right method: in this case, the C method with +the request object. This method will usually do any actions which are +required, including modifying the list of objects to be passed to the +template, or the name of the template to be called. + +=head1 Template class processing + +Finally, the template processor is handed the objects, the template +name, and various other bits and pieces, and tries to find the right +template. It does this by looking first for C: that is, a +specific template appropriate to the class. Next, it looks at +C, a local modification, before looking for +C, one of the default templates that came with +C. + +=head2 Default template arguments + +The following things are passed to the Template Toolkit template by +default: + +=over 3 + +=item request + +The whole C request object, for people getting really dirty +with the templates. + +=item objects + +The objects handed to us by the model. + +=item base + +The base URL of the application. + +=item config + +The whole configuration hash for the application. + +=item classmetadata + +A hash consisting of: + +C - The name of the model class for the request: e.g. C. + +C - The names of the columns in this class. + +C - A hash mapping between the database's idea of a column +name and a human-readable equivalent. (C should be mapped to +C, perhaps.) + +C - A list of accessors which are not exactly fields +in the table but are related by a has-many relationship. For instance, +breweries have many beers, so C would appear in the list. + +C - The human-readable name for the class: C. + +C - The same, only plural: C. + +C - A hash mapping columns and C objects +representing a form field for editing that column. + +C - (Perhaps) a user-supplied description of the class. + +=back + +Additionally, depending on the number of objects, there will be an alias +for the C slot with the name of the moniker or plural moniker. + +That sounds a bit tricky, but what it means is that if you look at +C then C will be populated with a C +object with ID 4. On the other hand, if you look at C you +can get all the beers in C as well as in C. + -=head2