]> git.decadent.org.uk Git - maypole.git/commitdiff
Fixed description of how Maypole::Application loads plugins, in Mp::Manual::Inheritance.
authorDavid Baird <cpan.zerofive@googlemail.com>
Tue, 1 Nov 2005 11:07:42 +0000 (11:07 +0000)
committerDavid Baird <cpan.zerofive@googlemail.com>
Tue, 1 Nov 2005 11:07:42 +0000 (11:07 +0000)
git-svn-id: http://svn.maypole.perl.org/Maypole/trunk@404 48953598-375a-da11-a14b-00016c27c3ee

lib/Maypole/Manual/Inheritance.pod
lib/Maypole/Model/CDBI.pm

index 1c2fca93837bf4241cd341d1660fd0d2146a2dec..68f221140d5790a1398ece53816ee8552cdf468b 100644 (file)
@@ -37,22 +37,23 @@ A minimal Maypole application (such as the Beer database) consists of a
 custom driver class (BeerDB.pm), a set of auto-generated model classes, and a \r
 view class: \r
 \r
+\r
                   THE DRIVER\r
                                           +------- init() is a factory method,\r
                    1      Maypole         |           it sets up the view\r
    Maypole::Config <----- config();       |              classes\r
    model();               init(); *-------+                           THE VIEW\r
-    |                     view_object(); -------+              \r
+    |                     view_object(); -------+\r
     |    +--------------* setup();              |      Maypole::View::Base\r
     |    |                   +                  |              +\r
     |    |                   |                  |     1        |\r
-    |    |               Apache::MVC *-----+    +-----> Maypole::View::TT\r
-    |    |                   +             |             (or another view class)\r
-    |    |                   |             |\r
-    |    |                PLUGINS          |\r
-    |    |                   +             |\r
-    |    |                   |             +----- or CGI::Maypole\r
-    |    |                BeerDB                   or MasonX:::Maypole\r
+    |    |    PLUGINS    Apache::MVC *-----+    +-----> Maypole::View::TT\r
+    |    |       +           +             |             (or another view class)\r
+    |    |       |           |             |\r
+    |    |       +-----+-----+             |\r
+    |    |             |                   |\r
+    |    |           BeerDB                +----- or CGI::Maypole\r
+    |    |                                         or MasonX:::Maypole\r
     |    |\r
     |   setup() is a factory method,\r
     |     it sets up the model\r
@@ -62,10 +63,10 @@ view class:
     |\r
     |  Maypole::Model::Base   Class::DBI\r
     |             +             +\r
-    |             |             |                             \r
-    +-------> Maypole::Model::CDBI                            \r
-                      +                                       \r
-                      |                                       \r
+    |             |             |\r
+    +-------> Maypole::Model::CDBI\r
+                      +\r
+                      |\r
            +------------+--------+-------+---------+\r
            |            |        |       |         |\r
        BeerDB::Pub      |   BeerDB::Beer | BeerDB::Brewery\r
@@ -76,24 +77,20 @@ view class:
           pub();                      BeerDB::Style\r
           beer();                     beers();\r
 \r
-\r
 =head2 What about Maypole::Application - loading plugins\r
 \r
-The main job of L<Maypole::Application> is to insert the plugins into the \r
-hierarchy. It ensures that L<BeerDB> inherits from the first plugin, which \r
-inherits from the next, etc., until the last plugin inherits from the frontend. \r
-\r
-It is also the responsibility of L<Maypole::Application> to decide which \r
-frontend to use. \r
+The main job of L<Maypole::Application> is to insert the plugins into the\r
+hierarchy. It is also the responsibility of L<Maypole::Application> to decide\r
+which frontend to use. It builds the list of plugins, then pushes them onto the\r
+driver's C<@ISA>, then pushes the frontend onto the end of the driver's C<@ISA>.\r
+So method lookup first searches all the plugins, before searching the frontend\r
+and finally L<Maypole> itself.\r
 \r
 From Maypole 2.11, L<Maypole::Application> makes no appearance in the\r
 inheritance structure of a Maypole application. (In prior versions,\r
 L<Maypole::Application> would make itself inherit the plugins, and then insert\r
 itself in the hierarchy, but this was unnecessary).\r
 \r
-The order of inheritance is the same as the order in which plugins are supplied \r
-in the C<use Maypole::Application> statement. \r
-\r
 =head2 Who builds the model?\r
 \r
 First, remember we are talking about the standard, unmodified Maypole here. \r
index 8de426a7ff409e610b94afaea9b978da39e3a678..df8d6c8b210094f3bc23703ae8e0a1f8bc522248 100644 (file)
@@ -256,7 +256,7 @@ sub setup_database {
 
 sub class_of {
     my ( $self, $r, $table ) = @_;
-    return $r->config->loader->_table2class($table);
+    return $r->config->loader->_table2class($table); # why not find_class ?
 }
 
 sub fetch_objects {