-However, in many applications, a more complex domain model is required, or may \r
-already exist. In this case, the Maypole model is more clearly seen as a layer \r
-that sits on top of the custom domain model, and controls access to it from \r
-the web UI. In this kind of situation, it seems more helpful to think of the \r
-Maypole model as part of the controller. This conceptualisation helps developers \r
-maintain a separation between the Maypole model classes, and their own domain \r
-model. Without this distinction, developers may add domain-specific code \r
-to the Maypole model classes, ending up with two separate code bases \r
-intermingled within one set of files. \r
-\r
-To a certain extent, this is fine. But if you find yourself adding lots on\r
+However, in many applications, a more complex domain model is required, or may\r
+already exist (see L<Maypole::Manual::Inheritance>). In this case, the Maypole\r
+model is more clearly seen as a layer that sits on top of the custom domain\r
+model, and controls access to it from the web UI. In this kind of situation, it\r
+seems more helpful to think of the Maypole model as part of the controller (or\r
+as a Presentation Model - see below).\r
+\r
+This conceptualisation helps developers maintain a separation between the\r
+Maypole model classes, and their own domain model. Without this distinction,\r
+developers may add domain-specific code to the Maypole model classes. To a\r
+certain extent, this is fine. But if you find yourself adding lots of\r