Pages classes receive requests from users’ web browsers, delegate any required processing to various other classes, and call up the appropriate Smarty template to generate a response (if necessary). All page classes are located in the
pages directory, and each of them must extend the
Handler class (see
Additionally, page classes are responsible for ensuring that user requests are valid and any authentication requirements are met. As much as possible, user-submitted form parameters and URL parameters should be handled in Page classes and not elsewhere, unless a Form class is being used to handle parameters.
An easy way to become acquainted with the tasks a Page class must fulfill is to examine a typical one. The file
pages/about/AboutHandler.inc.php contains the code implementing the class
AboutHandler, which handles requests such as
http://www.mylibrary.com/ojs2/myjournal/about/siteMap. This is a fairly simple Page class responsible for fetching and displaying various metadata about the journal and site being viewed.
Each Page class implements a number of functions that can be called by the user by addressing the appropriate Page class and function in the request URL. (See the section titled “Request Handling” for more information on the mapping between URLs and page classes.)
Often, Page classes handle requests based on the role the user is playing. For example, there is a Page class called
AuthorHandler (in the directory
pages/author/AuthorHandler.inc.php) that delegates processing of the various tasks an author might perform. Similarly, there are classes called
ManagerHandler, and so forth.
The number of tasks a Page handler must perform can frequently be considerable. For example, if all requests for Section Editor functions were handled directly by the
SectionEditorHandler class, it would be extremely large and difficult to maintain. Instead, functions are further subdivided into several other classes (such as
SectionEditorHandler itself remaining just to invoke the specific subclass.