Reorganised pod in Maypole.pm, finished doc roadmap, various minor pod updates, moved...

[maypole.git] / lib / Maypole / Manual / Terminology.pod

diff --git a/lib/Maypole/Manual/Terminology.pod b/lib/Maypole/Manual/Terminology.pod
index 05b321ef1c88e055bc78f0a949b6ef07b6a3bcbf..1871910c3b232cb4e60493b314881d878de744ac 100644 (file)
--- a/lib/Maypole/Manual/Terminology.pod
+++ b/lib/Maypole/Manual/Terminology.pod
@@ -21,6 +21,13 @@ L<Maypole::Application> to set up your app (not recommended for newbies, but
 common enough), the driver class will directly inherit from one of Maypole's \r
 frontend classes. \r
 \r
 common enough), the driver class will directly inherit from one of Maypole's \r
 frontend classes. \r
 \r

+=item controller\r
+\r
+Occasionally this term is used in place of C<driver>.\r
+\r
+See the entry below (MVC) for the main usage of the term C<controller> within \r
+Maypole. \r
+\r

 =item application\r
 \r
 Sometimes this is used to refer to the driver, but this term is best reserved \r
 =item application\r
 \r
 Sometimes this is used to refer to the driver, but this term is best reserved \r


@@ -88,8 +95,12 @@ A file used to generate HTML for part or all of a web page. Maypole currently
 supports Template Toolkit and Mason as templating languages, but others could \r
 be added easily.\r
 \r
 supports Template Toolkit and Mason as templating languages, but others could \r
 be added easily.\r
 \r

+=back\r
+\r

 =head2 MVC and Maypole\r
 \r
 =head2 MVC and Maypole\r
 \r

+=over 4\r
+\r

 =item MVC - Model-View-Controller\r
 \r
 A pattern describing separation of concerns in a complex application. The \r
 =item MVC - Model-View-Controller\r
 \r
 A pattern describing separation of concerns in a complex application. The \r


@@ -100,21 +111,22 @@ Opinions vary between how closely Maypole adheres to this pattern.
 \r
 Here's one opinion:\r
 \r
 \r
 Here's one opinion:\r
 \r

-=over 4\r
-\r

 =item controller\r
 \r
 An abstract concept in Maypole, i.e. there is no specific controller class. \r
 \r
 =item controller\r
 \r
 An abstract concept in Maypole, i.e. there is no specific controller class. \r
 \r

-The main sequence of events that occur during the processing of a request is \r
-controlled by methods in L<Maypole>. Thus, major parts of the controller are in \r
-the same class as the request object. This may seem a bit strange, but in \r
+The main sequence of events that occur during the processing of a request is\r
+controlled by methods in C<Maypole.pm>. Thus, major parts of the controller are\r
+in the same class as the request object. This may seem a bit strange, but in\r

 practice it works well.\r
 \r
 More detailed events within the processing of a request are actually handled by \r
 methods in the Maypole 'model'. For instance, switching from one template to \r
 another. \r
 \r
 practice it works well.\r
 \r
 More detailed events within the processing of a request are actually handled by \r
 methods in the Maypole 'model'. For instance, switching from one template to \r
 another. \r
 \r

+Be aware that occasionally authors refer to the C<controller> when they are\r
+describing the C<driver>.\r
+\r

 =item model\r
 \r
 In Maypole, the model is the set of classes representing individual tables in \r
 =item model\r
 \r
 In Maypole, the model is the set of classes representing individual tables in \r