A Model-View-Controller perspective of Elgg
This section provides an overview of Elgg through the lens of the MVC pattern.
Overview
It all starts with a request. The most common scenario is a web browser requesting an HTML page. Let's assume it is a request for the web page that displays Joe's latest vacation photos. The request arrives at the controller. The controller confirms that Joe exists as a user at the site. It tells the model to increment the view counter on the photo album. The controller then passes the album identifier over to the view for rendering. The view pulls the photo objects from the model and creates the HTML page that is sent to the web browser.
Controllers
Elgg uses the Front Controller pattern with a twist. In the Front Controller pattern, every request is routed through a single controller. This is unlike web applications that use individual scripts to handle different types of requests (for example, logging in uses login.php, posting a comment uses post-comment.php, and so on). The twist with Elgg's implementation of this pattern is that it has two primary front controllers. One front controller handles actions, which usually involve the submission of a form. The other front controller handles requests for pages, which are most often HTML pages.
The job of the front controller is loading the framework and dispatching the request to the appropriate secondary controller. A page controller processes the parameters of the request, updates the data model, and turns the processed request over to the views system. An action controller is similar except that it does not turn a request over to the views system, but instead forwards the requester to a new page. In Elgg, these controllers are called handlers.
The following diagram shows request processing logic inside the controller box of the overview diagram. The diagram includes three of the page handlers provided by plugins as examples of secondary controllers.
The two primary handlers are located at /engine/handlers/.
Model
The model of Elgg consists of three parts:
Data model classes that manage entities, metadata, and relationships.
Helper functions that build queries based on parameters (give me the 10 latest blog posts written by Bob).
Database access layer that provides an interface to the MySQL database.
The data model supports a wide range of use cases because of its simple and flexible design. Developers should use Elgg's data model rather than writing their own queries or creating their own tables.
Views
The views system renders data into HTML (or other formats such as RSS). It has two steps. In the first step, the controller requests the view system to render the data from the model for presentation. In the second step, this output is inserted into a layout and the complete response is rendered. This is different from frameworks that use a per page template that lays out an entire page. An advantage of the two step approach is the ease of maintaining a consistent look across all pages.
The output from the first step is represented by the content box in the following diagram. The second step handles the remaining sections of a page.
Both steps use templates which are called views in Elgg. Views are short scripts that provide building blocks for creating web pages and other types of output. In the preceding diagram, the topbar, header, sidebar, and footer are created by views. As mentioned earlier, PHP is the template language used in the views.
Each request has a view type that determines the response format. If the view type is default, then an HTML page is created. If it is json, then the same data is rendered in JSON format. The view type is set by the controller based on the parameters of the request. This view type functionality can be used to serve a mobile-specific layout to mobile devices. An example of this can be found in Chapter 9.
