X-Git-Url: https://git.decadent.org.uk/gitweb/?a=blobdiff_plain;f=lib%2FMaypole%2FManual%2FInheritance.pod;h=a20740578a0cde8813474e368439245200592354;hb=ad24ffc85f25a9b73a28cd326c3b3caea234adbf;hp=2dd0eaf0f6e2048d2e6b4569eeebf9115c5afd68;hpb=1b05e3ca38fdb958cf9ced4d89e1478dc1e21257;p=maypole.git

diff --git a/lib/Maypole/Manual/Inheritance.pod b/lib/Maypole/Manual/Inheritance.pod
index 2dd0eaf..a207405 100644
--- a/lib/Maypole/Manual/Inheritance.pod
+++ b/lib/Maypole/Manual/Inheritance.pod
@@ -16,8 +16,7 @@ application.
 
         +
         |
-    +--  --+
-        |
+     +-   -+
 	|
 	+
 	
@@ -37,22 +36,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 
 view class: 
 
+
                   THE DRIVER
                                           +------- init() is a factory method,
                    1      Maypole         |           it sets up the view
    Maypole::Config <----- config();       |              classes
    model();               init(); *-------+                           THE VIEW
-    |                     view_object(); -------+              
+    |                     view_object(); -------+
     |    +--------------* setup();              |      Maypole::View::Base
     |    |                   +                  |              +
     |    |                   |                  |     1        |
-    |    |               Apache::MVC *-----+    +-----> Maypole::View::TT
-    |    |                   +             |             (or another view class)
-    |    |                   |             |
-    |    |                PLUGINS          |
-    |    |                   +             |
-    |    |                   |             +----- or CGI::Maypole
-    |    |                BeerDB                   or MasonX:::Maypole
+    |    |    PLUGINS    Apache::MVC *-----+    +-----> Maypole::View::TT
+    |    |       +           +             |             (or another view class)
+    |    |       |           |             |
+    |    |       +-----+-----+             |
+    |    |             |                   |
+    |    |           BeerDB                +----- or CGI::Maypole
+    |    |                                         or MasonX:::Maypole
     |    |
     |   setup() is a factory method,
     |     it sets up the model
@@ -62,10 +62,10 @@ view class:
     |
     |  Maypole::Model::Base   Class::DBI
     |             +             +
-    |             |             |                             
-    +-------> Maypole::Model::CDBI                            
-                      +                                       
-                      |                                       
+    |             |             |
+    +-------> Maypole::Model::CDBI
+                      +
+                      |
            +------------+--------+-------+---------+
            |            |        |       |         |
        BeerDB::Pub      |   BeerDB::Beer | BeerDB::Brewery
@@ -76,24 +76,20 @@ view class:
           pub();                      BeerDB::Style
           beer();                     beers();
 
-
 =head2 What about Maypole::Application - loading plugins
 
-The main job of L<Maypole::Application> is to insert the plugins into the 
-hierarchy. It ensures that L<BeerDB> inherits from the first plugin, which 
-inherits from the next, etc., until the last plugin inherits from the frontend. 
-
-It is also the responsibility of L<Maypole::Application> to decide which 
-frontend to use. 
+The main job of L<Maypole::Application> is to insert the plugins into the
+hierarchy. It is also the responsibility of L<Maypole::Application> to decide
+which frontend to use. It builds the list of plugins, then pushes them onto the
+driver's C<@ISA>, then pushes the frontend onto the end of the driver's C<@ISA>.
+So method lookup first searches all the plugins, before searching the frontend
+and finally L<Maypole> itself.
 
 From Maypole 2.11, L<Maypole::Application> makes no appearance in the
 inheritance structure of a Maypole application. (In prior versions,
 L<Maypole::Application> would make itself inherit the plugins, and then insert
 itself in the hierarchy, but this was unnecessary).
 
-The order of inheritance is the same as the order in which plugins are supplied 
-in the C<use Maypole::Application> statement. 
-
 =head2 Who builds the model?
 
 First, remember we are talking about the standard, unmodified Maypole here. 
@@ -238,6 +234,14 @@ C<BeerDB2::Beer>, then C<BeerDB2::Maypole::Model>, C<Maypole::Model::CDBI>,
 C<Maypole::Model::Base>, and C<Class::DBI>, before moving on to
 C<OfflineBeer::Beer> and finally C<OfflineBeer>.
 
+B<CAVEAT> - if your Offline model overrides L<Class::DBI> methods, these methods
+will B<not> be overridden when called from the Maypole application, because the
+Maypole model provides an alternative path to L<Class::DBI> which is searched
+first. The solution is to place such methods in a separate package, e.g.
+C<OfflineBeer::CDBI>. Place this B<first> in the C<@ISA> of both
+C<BeerDB2::Maypole::Model> and C<OfflineBeer>. Note that C<OfflineBeer::CDBI>
+does not itself need to inherit from L<Class::DBI>.
+
 Methods defined in the Maypole model base class (C<BeerDB2::Maypole::Model>),
 override methods in the individual Offline table classes, and in the Offline
 model base class (C<Offline>). 
@@ -262,3 +266,16 @@ Whatever label you prefer to use, this approach provides for clear separation of
 concerns between the underlying model and the web/user interface, and that's
 what it's all about.
           
+=head1 AUTHOR
+
+David Baird, C<< <cpan@riverside-cms.co.uk> >>
+
+=head1 COPYRIGHT & LICENSE
+
+Copyright 2005 David Baird, All Rights Reserved.
+
+This text is free documentation; you can redistribute it and/or modify it
+under the same terms as the Perl documentation itself.
+
+=cut
+