]> git.decadent.org.uk Git - maypole.git/commitdiff
Modified Manual/Inheritance.pod in response to Kieren's email to the list.
authorDavid Baird <cpan.zerofive@googlemail.com>
Tue, 8 Nov 2005 11:31:23 +0000 (11:31 +0000)
committerDavid Baird <cpan.zerofive@googlemail.com>
Tue, 8 Nov 2005 11:31:23 +0000 (11:31 +0000)
git-svn-id: http://svn.maypole.perl.org/Maypole/trunk@419 48953598-375a-da11-a14b-00016c27c3ee

lib/Maypole/Manual/Inheritance.pod
wishlist.txt

index 6c6c6b77eba53e34624cf88766ec64bb52017412..bff339db3bd467b82f5cf6c59d90c3df1c573026 100644 (file)
@@ -30,11 +30,11 @@ application.
 \r
 =back\r
 \r
-=head1 A standard Maypole application\r
+=head1 Structure of a standard Maypole application\r
 \r
-A minimal Maypole application (such as the Beer database) consists of a \r
-custom driver class (BeerDB.pm), a set of auto-generated model classes, and a \r
-view class: \r
+A minimal Maypole application (such as the Beer database example from the\r
+L<Maypole> synopsis) consists of a custom driver class (BeerDB.pm), a set of\r
+auto-generated model classes, and a view class:\r
 \r
 \r
            THE DRIVER\r
@@ -92,9 +92,10 @@ itself in the hierarchy, but this was unnecessary).
 \r
 =head2 Who builds the model?\r
 \r
-First, remember we are talking about the standard, unmodified Maypole here. \r
-It is possible, and common, to override some or all of this stage and build a \r
-customised model.\r
+First, remember we are talking about the standard, unmodified Maypole here. It\r
+is possible, and common, to override some or all of this stage and build a\r
+customised model. See below - An advanced Maypole application - for one\r
+approach. Also, see L<Maypole's|Maypole> C<setup_model()> method. \r
 \r
 The standard model is built in 3 stages. \r
 \r
@@ -110,10 +111,12 @@ Next, C<Maypole::setup> B<unshifts> L<Maypole::Model::CDBI> onto the C<@ISA>
 array of each of these classes. \r
 \r
 Finally, the relationships among these tables are set up. Either do this\r
-manually, perhaps with the help of L<Class::DBI::Relationship>, or use\r
-L<Maypole::Plugin::Relationship>. In the latter case, you need to set up the\r
-relationships configuration before calling C<setup()>.\r
-\r
+manually, using the standard L<Class::DBI> syntax for configuring table\r
+relationships, or try L<Class::DBI::Relationship> (which you can use via\r
+L<Maypole::Plugin::Relationship>). If you use the plugin, you need to set up the\r
+relationships configuration before calling C<setup()>. Be aware that some people\r
+like the convenience of L<Class::DBI::Relationship>, others dislike the\r
+abstraction. YMMV. \r
 \r
 =head1 An advanced Maypole application\r
 \r
@@ -270,6 +273,20 @@ calls on the underlying model.
 Whatever label you prefer to use, this approach provides for clear separation of\r
 concerns between the underlying model and the web/user interface, and that's\r
 what it's all about.\r
+\r
+=head1 Advanced applications - building the model by hand ** TODO\r
+\r
+- using Maypole::Model::CDBI::Plain or Maypole::FormBuilder::Model::Plain\r
+- setup_model() and load_model_subclass()\r
+- cutting out all those separate paths to CDBI - they're confusing \r
+\r
+\r
+=head1 Method inheritance ** TODO\r
+\r
+More description of Perl's left-to-right, depth-first method lookup, and where\r
+it's particularly important in Maypole.\r
+\r
+\r
           \r
 =head1 AUTHOR\r
 \r
index 21cdea978b4c0ffb7063165f41e3fa194b2a3a70..8a73797503edb1a40084486400f38075b91d8058 100644 (file)
@@ -11,6 +11,8 @@ Move template test out of process() and into handler_guts() - maybe
 Fix bug 14570 - returning error codes breaks CGI::Maypole\r
 Write Maypole::Manual::Exceptions\r
 \r
+Fix Mp::P::USC\r
+\r
 2.12\r
 ====\r
 Maypole::instance()\r
@@ -24,7 +26,7 @@ in HTTP::Response object
 \r
 add email handling - like Rails - via model plugins\r
 \r
-add validation layer, or just an API\r
+add validation layer(s), or just an API\r
 \r
-killer apps: SVN model; mitiki; Pet Shop;\r
+killer apps: SVN model; mitiki; Pet Shop; \r
 \r