=head1 NAME Maypole::Manual::Terminology - common terms =head1 VERSION This version written for Maypole 2.11 =head1 TERMINOLOGY For the avoidance of confusion, the following terms are defined. We'll try and ensure the Maypole docs stick to these usages. =over 4 =item driver The custom package written to set up a Maypole application. This is the package that has the C statement. If you're not using L to set up your app (not recommended for newbies, but common enough), the driver class will directly inherit from one of Maypole's frontend classes. =item controller Occasionally this term is used in place of C. See the entry below (MVC) for the main usage of the term C within Maypole. =item application Sometimes this is used to refer to the driver, but this term is best reserved to refer to the complete application, i.e. driver, plugins, templates, model, the whole shebang. =item frontend An adapter class that allows Maypole to work in a number of different server environments. The currently available frontends are: Frontend Distribution Environment ============================================== CGI::Maypole Maypole CGI Apache::MVC Maypole Apache/mod_perl and Apache2/mod_perl2 MasonX::Maypole MasonX::Maypole Apache/mod_perl with Mason The driver class inherits from the appropriate frontend, which inherits from L. =item backend Confusingly, sometimes you'll see the frontend referred to as the backend. It depends on your point of view. Also confusingly, the Maypole model (e.g. L) is sometimes referred to as the backend. You'll just need to pay attention to context. In general, it's probably best to avoid using this term altogether. =item request The Maypole request object. =item workflow The sequence of events when a browser sends a request to a Maypole application. You will also often see this referred to as the C (distinct from the request object). =item Exported method A method in a Maypole model class that is labelled with the C attribute. These methods are mapped to part of the request URI. So requesting a path will result in a particular method being called on a particular model class. =item action An Exported method. Note: not the action attribute of a form, although the form's action URI will generally include a Maypole action component. =item command In some templates, an C is called a C. =item template 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 be added easily. =back =head2 MVC and Maypole =over 4 =item MVC - Model-View-Controller A pattern describing separation of concerns in a complex application. The C represents the domain or business logic. The C represents the user interface. The C mediates the interaction between the two. Opinions vary between how closely Maypole adheres to this pattern. Here's one opinion: =item controller An abstract concept in Maypole, i.e. there is no specific controller class. The main sequence of events that occur during the processing of a request is controlled by methods in C. Thus, major parts of the controller are in the same class as the request object. This may seem a bit strange, but in practice it works well. More detailed events within the processing of a request are actually handled by methods in the Maypole 'model'. For instance, switching from one template to another. Be aware that occasionally authors refer to the C when they are describing the C. =item model In Maypole, the model is the set of classes representing individual tables in the database. Tables are related to each other in a more or less complex way. Each table class inherits from a Maypole model class, such as L or L. In fact, much of the functionality provided by the Maypole model class, may be better thought of as being controller code. And much of the custom code written by developers to support specific applications, is in fact controller code. The distinction is probably unimportant when using Maypole in 'default' mode - i.e. using L, and allowing Maypole to autogenerate the 'model' classes straight out of the database. However, in many applications, a more complex domain model is required, or may already exist. In this case, the Maypole model is more clearly seen as a layer that sits on top of the custom domain model, and controls access to it from the web UI. In this kind of situation, it seems more helpful to think of the Maypole model as part of the controller. This conceptualisation helps developers maintain a separation between the Maypole model classes, and their own domain model. Without this distinction, developers may add domain-specific code to the Maypole model classes, ending up with two separate code bases intermingled within one set of files. To a certain extent, this is fine. But if you find yourself adding lots on non-Exported methods to your Maypole model classes, and these methods are not there to support Exported methods, consider whether you could separate out the domain model into a separate hierarchy of classes that you import into the Maypole model. The distinction between the Maypole model, the domain model, and the model in the MVC pattern, is fuzzy and variable. In straightforward Maypole applications, they're all pretty much the same thing. In more advanced applications, they begin to diverge. Take care out there. =item view This is represented in Maypole by the view class (L, L, or L), and by the templates. =back =head1 AUTHOR David Baird, C<< >> =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