X-Git-Url: https://git.decadent.org.uk/gitweb/?a=blobdiff_plain;f=lib%2FMaypole%2FManual%2FInheritance.pod;h=6c6c6b77eba53e34624cf88766ec64bb52017412;hb=0792cc02d2de53e250d0178e4850ef84f3ce23f1;hp=1c2fca93837bf4241cd341d1660fd0d2146a2dec;hpb=672f0445d8c46ff29b0c6ebf18d30791c017260a;p=maypole.git diff --git a/lib/Maypole/Manual/Inheritance.pod b/lib/Maypole/Manual/Inheritance.pod index 1c2fca9..6c6c6b7 100644 --- a/lib/Maypole/Manual/Inheritance.pod +++ b/lib/Maypole/Manual/Inheritance.pod @@ -16,8 +16,7 @@ application. + | - +-- --+ - | + +- -+ | + @@ -37,35 +36,36 @@ 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 + + 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 | classes | - | THE MODEL + | THE MODEL | - | Maypole::Model::Base Class::DBI - | + + - | | | - +-------> Maypole::Model::CDBI - + - | + | Maypole::Model::Base Class::DBI + | + + + + | | | | + +-------> Maypole::Model::CDBI Class::DBI:: + + + + | | +------------+--------+-------+---------+ | | | | | 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 is to insert the plugins into the -hierarchy. It ensures that L 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 to decide which -frontend to use. +The main job of L is to insert the plugins into the +hierarchy. It is also the responsibility of L 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 itself. From Maypole 2.11, L makes no appearance in the inheritance structure of a Maypole application. (In prior versions, L 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 statement. - =head2 Who builds the model? First, remember we are talking about the standard, unmodified Maypole here. @@ -102,10 +98,13 @@ customised model. The standard model is built in 3 stages. -First, C calls C on the Maypole model class, in -this case L. C then uses +First, C calls C on the Maypole model +class, in this case L. C then uses L to autogenerate individual L classes for each of the tables in the database (C, C etc). +L identifies the appropriate L subclass and +inserts it into each of these table classes' C<@ISA> ( C<< +Class::DBI:: >> in the diagrams).. Next, C B L onto the C<@ISA> array of each of these classes. @@ -181,8 +180,8 @@ C, you would write: use base 'OfflineBeer::Beer'; 1; -This package will be loaded automatically during C, and -C is B onto it's C<@ISA>. +From Maypole 2.11, this package will be loaded automatically during C, +and C is B onto it's C<@ISA>. Configure relationships either in the individual C classes, or else all together in C itself i.e. not in the Maypole model. This @@ -195,15 +194,16 @@ The resulting model looks like this: | Maypole::Model::Base | + | - | +----------------------+-----------------+ - | | | - | | | - Maypole::Model::CDBI | OFFLINE - + | MODEL - | | - BeerDB2::Maypole::Model OfflineBeer - + + - | | + | +-----------------+----+-----------------+ + | | | | + | | | | + Maypole::Model::CDBI | | OFFLINE + + | | MODEL + | | | + BeerDB2::Maypole::Model Class::DBI:: OfflineBeer + + + + + | | | + +-----------------------------+ | | | +--- BeerDB2::Pub --------+ OfflineBeer::Pub --------+ | beers(); | @@ -227,10 +227,10 @@ The resulting model looks like this: =head3 Features -Non-Maypole applications using the Offline model are completely isolated from +1. Non-Maypole applications using the Offline model are completely isolated from the Maypole application, and need not know it exists at all. -Methods defined in the Maypole table classes, override methods defined in the +2. Methods defined in the Maypole table classes, override methods defined in the Offline table classes, because C was unshifted onto the beginning of each Maypole table class's C<@ISA>. Perl's depth first, left-to-right method lookup from e.g. C starts in @@ -246,13 +246,14 @@ C. Place this B in the C<@ISA> of both C and C. Note that C does not itself need to inherit from L. -Methods defined in the Maypole model base class (C), +3. Methods defined in the Maypole model base class (C), override methods in the individual Offline table classes, and in the Offline model base class (C). -Relationships defined in the Offline classes are inherited by the Maypole model. +4. Relationships defined in the Offline classes are inherited by the Maypole +model. -The Maypole model has full access to the underlying Offline model. +5. The Maypole model has full access to the underlying Offline model. =head3 Theory