Maypole::Application supports Maypole::HTTPD (which needs a patch).

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

diff --git a/lib/Maypole/Manual/Terminology.pod b/lib/Maypole/Manual/Terminology.pod
index d7bf7f433e315a4d9f0827328df1e18438518517..adc5dc85b64d017782b9db0d8d78d5d0d4739c0a 100644 (file)
--- a/lib/Maypole/Manual/Terminology.pod
+++ b/lib/Maypole/Manual/Terminology.pod
@@ -151,7 +151,7 @@ The functionality provided by the Maypole model class is more accurately
 described as a Presentation Model (see below). In complex Maypole applications,\r
 it is good practise to separate the domain model (the 'heart' of the\r
 application) into a separate class hierarchy (see\r
-L<Maypole::Manual::Inheritance).\r
+L<Maypole::Manual::Inheritance>).\r
 \r
 The distinction is relatively unimportant when using Maypole in 'default' mode - \r
 i.e. using L<Maypole::Model::CDBI>, and allowing Maypole to autogenerate the \r
@@ -179,6 +179,8 @@ point, the convenience of dropping new methods into the 'shared' classes will be
 outweighed by the heuristic advantage of separating different layers into\r
 separate class hierarchies.\r
 \r
+=back\r
+\r
 =head3 Presentation Model\r
 \r
 This pattern more accurately describes the role of the Maypole model.\r
@@ -196,8 +198,6 @@ queries the Presentation Model to retrieve these new values. In Maypole, this is
 the role of the C<vars()> method on L<Maypole::View::Base>, which transmits the\r
 new values to the templates.\r
 \r
-=back\r
-\r
 =head1 AUTHOR\r
 \r
 David Baird, C<< <cpan@riverside-cms.co.uk> >>\r