Joomla is an object-oriented application. The Joomla framework has been developed as a series of classes that work together to provide the content management system (CMS) functionality. Developing for Joomla effectively requires that certain object-oriented concepts be understood and adopted. One of these concepts is the use of design patterns for development. Design patterns are essentially conceptual models that direct the way new object-oriented programming is approached.
Design patterns are models that have been refined over many projects so that, if properly matched to the problem that you are trying to solve, can supply a proven effective methodology to solving that problem. Adoption of effective design patterns means that development schedules are easier to keep, maintenance of the system is cheaper, communication about the evolving system is clearer, and new developers will have an easier time programming the system. By following a design pattern, a developer essential avoids reinventing the wheel every time a new project is started.
Since Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides pioneered work in this field in the early 1990s, there have been many comprehensive explanations written. The original (and perhaps most important) book on the subject, Design Patterns: Elements of Reusable Object-Oriented Software (Boston: Addison-Wesley, 1995), laid the foundations for many of the patterns that are used up to the present day—including those you see in Joomla.
This chapter introduces the basic concepts of design patterns and, since the Joomla team has adopted them in the CMS design, describes how some of them apply to Joomla. When you understand the design philosophy behind Joomla, you will not only be able to build more effective Joomla extensions, you will also better recognize how the framework itself can be addressed, examined, and used.
Design patterns are object-oriented development outlines that reflect the fundamental aims and process of a development cycle. Design patterns are made to address a specific development problem and provide a pattern for how to reach the solution.
A pattern generally documented with the following information:
Name and classification — The name of the pattern and the general classification that will tell the type of pattern. Typically, the classification is one of the three primary types: creational, structural, or behavioral.
Problem — Describes the problem that the pattern is designed to solve.
Solution — Details the solution to the problem, including general conceptual models, processes, and objects involved.
Hypothesis — General description of what the pattern does, and how it will solve the problem.
Concrete example — A tangible example of how the pattern was used to solve a problem.
Applicability — Where the problem can be effectively applied, as well as the solution's limitations.
Consequences — The trade-offs of adopting the pattern and the dependencies created by the pattern's adoption.
Implementation tips — General advice for usage of the pattern.
It is important to note that design patterns are neither perfect nor meant to create dogma that must be rigidly applied. Design patterns are guides, and generally the closer you stick to the pattern, the more advantages promised by the pattern will be reaped. However, practical considerations such as performance often intrude on strict adoption of a pattern.
Design patterns can be overkill if a project is very small. There is no easy way to determine the right size for when a pattern should be used. A general rule of thumb may be that if the project requires three or more developers now or in the future, then the design patterns will be worth implementing.
Individual developers, while not reaping the huge number of benefits from the practice of implementing patterns, may want to use them anyway for good habits so that use of them will become routine. That way, if the project expands, the best practices will already be in place.
Identify what benefits each pattern will provide, but don't slavishly abide by the pattern if it makes implementation impossible. The design patterns were made to streamline development, not inflexibly encase it in ivory tower commandments that require vast sacrifice to adopt.
To organize design patterns, the originators of the system divided them into three types:
Creational
Structural
Behavioral
Each of these categories represents a type of solitary pattern that can be used for good programming pattern definition.
Patterns that are classified as creational relate to the mechanisms of the creation of objects. It might seem like object creation is straightforward and mostly handled by the system. However, managed object creation can provide many benefits, such as streamlined upgrades or better resource sharing—particularly in a large system.
In many programming systems, creation of new objects is performed simply by calling the programming language's object creation function. However, there are many applications that can reap benefits by introducing a middleware application to handle object creation.
For example, database abstract layer (DAL) technology (such as PEAR DAL, PDO, and ADOdb) forms a middle layer between an application as a data source so that a programmer can write database access code that addresses the DAL, and the application can talk to any database back-end the DAL supports.
To make a connection, rather than creating a connection object directly, the application requests a connection object from the DAL. With this method, the DAL can perform connection pooling, so connections that have been created but released from the originating process can simply be handed to the new requestor, rather than creating a new connection from scratch. This creational pattern conserves precious server resources and, since the DAL handles the creation of connection objects directly, it can handle many of the special case problems of addressing particular data sources.
This is one real-world example of a creational pattern. Patterns held in the creational pattern category include abstract factory, factory method, builder, lazy initialization, object pool, prototype, and singleton. These pattern definitions specifically detail some of the processes that are needed by an application. The three most common creational patterns used by Joomla are the abstract factory pattern (which was used in this example), singleton pattern, and builder pattern.
One creational pattern is the abstract factory pattern whereby a factory class is constructed that accepts object creation requests and returns an instance of the specified class. If the object creation were to be coded into every aspect of the system, then a change in object class would require a rewrite and recompile of the system to allow the new class to be used.
A good example of using the abstract factory pattern is an encryption system. Imagine that there is a class called EncryptionA that provides routines to encrypt data for storage into a database. For this design pattern, an abstract factory could be created called EncryptionObject that would be called to obtain an instance of an EncryptionA object.
Now, imagine that time passes, and a flaw is found in the method used by EncryptionA. Therefore, a new class is created, called EncryptionB, that is more secure. To upgrade a system designed using the abstract factory pattern, only the EncryptionObject needs to be changed to respond to object requests with an EncryptionB object. If the EncryptionA object creation had been hard-coded into each program that needed encryption, large portions of the system would need to be upgraded and recompiled to use the new object. When EncryptionC is invented, without following the design pattern, another systemwide upgrade and recompile would be necessary.
The singleton pattern is a creational pattern used by Joomla classes—particularly for database access. In database applications, there is a great deal of overhead spent opening and closing database connections. To minimize this performance problem, the singleton pattern uses a single object to hold the database connection. The object is accessed by methods that need to address the connection to the database. Rather than creating new connections each time, the object will return a handle to the existing database connection.
In Joomla, a query to the database object is performed like this:
$db =& JFactory::getDBO(); $query = "SELECT *" . " FROM jos_messages" . " WHERE messageMonth = " . intval($curMonth); $db->setQuery($query); $myRows = $db->loadObjectList();
Using the object reference supplied by the getDBO() function allows the singleton connection of the current JFactory object to be reused.
The builder pattern is applied when conversions are necessary. The builder is actually a sort of plug-in for the parent class that is called the director. The director processes a file or input stream and parses it down to individual elements. Each element is sent to a builder, which returns a formatted output of the type that the builder was made to create.
Take the example of an XML processor class that is a director. It works through the XML tree and sends each tag and element to be processed by a builder class. The function of the builder class will depend on what it was designed to render. One builder may return a comma-delimited row for each element sent to it. Another builder may output SQL code to write the data of the elements into a database. In the builder pattern, each builder can be constructed independently of the director.
An example of the use of the builder pattern in Joomla would be the handler routines for the various user-configurable parameters of a module. These parameters are modifiable through the Module Manager in the Administrator interface of the Joomla system. To see the code that handles the various parameter types (text, textarea, radio button, filelist, and so on), open the element directory, which should have a path something like this:
htdocslibrariesjoomlahtmlparameterelement
This folder will contain a number of PHP files, one for each type of module parameter (such as filelist.php, imagelist.php, password.php, and so on). The director part of the Joomla framework loads the module parameters list and then calls the individual builder files to render the appropriate the appropriate HTML code back to the browser.
Structural patterns are related to the organization and process of a class. Classes within the framework that are organized around these patterns have specific inheritance characteristics. These patterns seek to simplify (as much as possible) the relationships between entities (or classes).
Patterns held in the structural patterns category include adapter, aggregate, bridge, composite, container, decorator, extensibility or framework, façade, flyweight, proxy, pipes and filters, private class data, and wrapper. The most common patterns used by Joomla include the adapter pattern and the bridge pattern.
The adapter pattern is used to allow one interface to use another, otherwise incompatible, interface. This pattern is used by Joomla bridge components that allow a technology such as the Simple Machines Forum to interoperate with the Joomla system. The bridge component provides a two-way adapter so that the incompatible systems can communicate.
The bridge pattern is used to abstract implementation by providing a standardized interface. The most common example of a bridge pattern is a generic printer system. The printer system feeds information through a standardized interface to any number of drivers. Since the output interface is abstracted, the user can switch printer drivers without reimplementation of the system's printer output.
An example of this pattern can be seen in the output type setting of a Joomla component. The type requested might be HTML, raw, text, and so on. These individual implementer classes will output in their various formats.
Behavioral patterns relate to the communication behavior of a class and its objects. These patterns seek to simplify and increase the flexibility of communications between entities.
Patterns held in the behavioral patterns category include chain of responsibility, command, interpreter, iterator, mediator, memento, observer, state, strategy, template, visitor, single-serving visitor, and hierarchical visitor. The most common patterns used by Joomla include the observer pattern, the chain-of-responsibility pattern, and the strategy pattern.
In the observer pattern, an object called the observable object is the common point for notifying other objects of a change in parameters. Each observer object registers itself with the observable object. When there is a change to the object that the observable represents, it notifies all registered observers.
A simple example is an auto-player on a USB system. Imagine an observable object created that watched the USB chain of devices. One of the observer objects registered with the observable is DVD player software. When a change occurs in the USB chain (such as a DVD inserted into a drive), all of the observers are notified. The DVD player observer would receive the notification of the change, determine whether a DVD movie was inserted, and automatically play the disc if set to do so.
Joomla uses the observer pattern for plug-in handling. Each plug-in registers with the Joomla system for the types of events that it might handle. When such an event occurs, the observable (Joomla) notifies the observer (plug-in) that a change has taken place.
Joomla plug-ins also comply with the chain-of-responsibility pattern. This pattern indicates that when an event occurs, that event is passed through a set of handlers. These handlers may be observers for the observer pattern. In the observer pattern, the observers are notified and no further behavior is expected from either the observer or the observable. In contrast, the chain-of-responsibility pattern queries the handlers as it makes each notification. If the observer acknowledges that it will handle the current event, the process stops, and no further observers are notified.
In a Joomla system, a plug-in may notify the system that it will handle the generated event, and the processing is handed off to the extension. Thereafter, no other action is performed by Joomla for that event.
In the strategy pattern, an algorithm is encapsulated within an object. That way, algorithms can be swapped, depending on the need to upgrade or reimplement without changing anything but the object passed for the algorithm activated. This strategy is commonly used for algorithms such as authentication and encryption/decryption.
This pattern is often used with the factory patterns. When the algorithm is changed, the new object is assigned within the factory to be passed to objects requesting one of those types.
While not part of the original Gang of Four patterns, concurrency patterns have become important, and will increase in importance. Within database specialist circles, concurrency is perhaps the primary problem. A typical large organization database system has potentially thousands of users attempting to access and modify the same data at the same time.
A typical airline ticket agent at an airport must determine whether he or she can sell a ticket or make a reservation for a particular flight at the moment a customer stands before them. The system must take into account when all flights that may be arriving, the current booking on a flight, what connecting flights (perhaps from other airlines) will use seats on the current flight, and even the predicted percentage of those who will not show up. All told, the program must take into account numerous instantaneous variables given the current availabilities and the ability to book a flight.
While this example is far from most Joomla uses (that don't have large-scale concurrent operations), more immediate examples such as two people (an editor and a chief editor) modifying the same article at the same time is extremely relevant. Joomla is a CMS, which means that at the most primitive level, it is likely that a contributor may be attempting to supplement an article at the same time a technical editor is editing for accuracy at the same time another editor is editing the grammar.
Therefore, examining a few concurrency patterns is important to understanding the uses these patterns have for managing concurrency conflict, now and in the future.
Architectural patterns are not specified in the original Gang of Four selection of patterns, but they are perhaps the most relevant to Joomla developers. These patterns present a general system architectural overview, showing how an entire software system might be created.
Most popular among these patterns is the client-server pattern. In the client-server pattern, a client executes a large amount of the processor-intensive calculations on the desktop platform, and communicates with the server for centralized database access. The client-server pattern allocates the majority of client interaction processing to the client (desktop machine), while the major data store occurs on the server, as shown in Figure 8-1.
In early Web development, the server-based pattern meant that all core processing occurred on the server. A simple Web browser could be used to access a server-based application. All data and program logic existed on the server, and the browser was used for simple display.
The new Ajax technologies described in Chapter 7 cut a middle road between the client-server pattern and the server-based pattern. While the application itself is server-based, the browser downloads a certain amount of logic to the client for execution (generally as JavaScript). Therefore, processing such as data validation and individual data process retrieval is performed on the client via execution code that is downloaded from the server.
While in the past Joomla has performed mostly under the server-based pattern, with the increasing adoption of the client-server pattern, Joomla is moving into the world of Web 2.0.
Figure 8-1. A client-server pattern places the user-interface processing on the client and the data coordination on the server.
Joomla is the essence of a server-based system. The client (browser) executes very little or no code. The server handles all queries, the presentation, and most code execution. Except for the article content editing (through TinyMCE, for example), all of the site processing occurs on the Web server (through PHP code), and the formatted page is then distributed to the Web browser.
Server-based patterns have perhaps the longest history in computer science. These go back to the punch cards that were fed into a central processor that then output the results, to the UNIX interfaces of the 1970s and 1980s, where dumb terminals were used to submit a process to the server and all execution occurred on the server platform.
While the client-server pattern took precedence in the era following the growth of the UNIX platform, the Web-based application interface temporarily returned the focus of the computer world to the server-based pattern. Many companies during the dot-com boom in the 1990s predicted that the server-based pattern would retake the position of the principal deployment model in the computer world. Poor server performance, discontinuous connections, and underpowered clients rendered this model unlikely. However, the widespread adoption of high-speed connections and powerful client devices has made the client-execution pattern likely to become a dominant pattern of the future.
In the client-execution pattern, code is downloaded from the server that will perform the most interactive functions on the client. Instead of performing validation on the server (such as making sure a ZIP code is accurate), the downloaded client code will query the server without an entire browser-page reload. If the ZIP code is invalid, the client code will prompt the user for further clarification. The ZIP code databases are generally large (about 8.5MB), making a database of ZIP codes impractical for client downloading.
However, by allowing client process querying (without the entire page update) on the entered ZIP code, the application can be as responsive as a common client-server implementation that includes the ZIP code database on the local drive.
Google has attempted to seize on this new pattern with a challenge to Microsoft's desktop application dominance with a suite known as Google Apps Premier Edition. This application suite uses the server platform for data storage and distribution, while harnessing the client's processing power to allow very interactive user-interface conventions.
The most important design patterns to Joomla are three design patterns (Observer, Composite, and Strategy) that are combined into the Model-View-Controller (MVC) pattern. The pattern seeks to break an application into three separate conceptual areas so that each can be developed as separately as possible from the others so that changes to one part have a minimum impact on the other parts.
In this pattern, each conceptual area represents a clear layer in the application:
Model — The logic or actual execution code of the application.
View — The presentation of graphics of text of the application.
Controller — The user interaction of the application including processing events.
If you think of these three areas in general terms in relation to Joomla, the Model would be the PHP and database code that executes on the Web server that is part of the Joomla framework. The View would be the template that determines how article content is displayed. The Controller would be the menu event system and extensions such as the search module that sends user requests into the Joomla model for processing.
With Joomla, templates provide an easy-to-understand representation of the advantages of keeping the three parts independent. Selecting a new template in the Template Manager can completely redefine the appearance of a Web site. If the Model and View were merged (as they have been in most past applications), the look-and-feel could be changed only with a great deal of custom programming.
Likewise, separating the user interface or Controller from the Model allows many ways for the user to interact with the application. In a simple example, the Controller might allow both a drop-down menu and a command key to activate the same function in the Model. Even more advanced would be a command line user interface or a graphical user interface (these two Controllers are available for MySQL) that allow the users to interact with the system using whichever method they prefer.
On a Web site, a separate Controller may come in the form of alternate text attributes for graphic menus and links that allow a vision-impaired person to navigate the graphical site. With accessibility functionality, a Web site can be accessed with a text-based browser (and through the text, a voice-based browser), and the Model can be controlled to retrieve article content.
Operating systems have been struggling for years to adopt the MVC model so that they could change their user interface based on the user's desire. One of the trade-offs of using MVC is that performance suffers. Since the separation means that each portion of the application is treated like a black box, information must be funneled from one layer to another—making optimization difficult. Partial adoption of the MVC model is one reason that operating systems have come a long way in enabling users to change the theme or view of the operating system, depending on user preferences. The lack of complete MVC adoption means that it is still difficult to make Mac OS look and feel like Windows Vista, or vice versa.
Like these operating systems, Joomla does not yet completely embrace this model. The templates themselves have a fair amount of PHP code logic (the Model) in them for proper execution. Likewise, the Controller aspects of modules are fairly tightly bound to their display (the View). As stated earlier, however, design patterns are an ideal to strive toward, not a straightjacket that requires all-or-nothing compliance.
While the implementation of the MVC model is not yet in perfect compliance with the pattern, the Joomla class framework is formally defined by an object for each portion of the model:
JModel— The class that acts as a factory for the model portion of the Joomla framework.JView— The class that acts as a factory for the presentation display portion of the Joomla framework.JController— The class that acts as a factory for the controller portion of the Joomla framework.
Within the Joomla system, it is components that are likely to be the most important places for a developer to implement the MVC pattern. Joomla components will often have all three of the layers of the pattern, while modules generally lack Controller aspects and plug-ins may only include Model logic.
In this section, you will use the MVC pattern to create a simple Hello World MVC component. Implementing this component will not only provide a good basic demonstration of how design patterns can be used in Joomla development, but it will hopefully also provide the impetus for you to begin looking at design patterns for possible solutions before you begin application implementation.
Components in Joomla lend themselves to the MVC pattern in that the three parts of the model can be located in separate files. A Joomla component that embraces the MVC pattern will need to be divided into the three parts of the pattern:
Model — The
hellomvc.phpfile will hold the core logic of the component.View — The
view.html.phpfile will contain the presentation rendering logic.Controller — The
controller.phpfile will handle all of the user interaction.
Begin by creating a folder called com_hellomvc. Within this main folder, create the following directories:
com_hellomvccontrollers com_hellomvcmodels com_hellomvcviews
In this example component file, you can see the controller extension addressed, while the system will automatically reference a default view unless instructed. Enter the following code and save it as hellomvc.php in the com_hellomvc directory:
<?php
/**
* @version $Id: hellomvc.php 7122 2007-06-21 11:52:29Z danr $
* @package hellomvc
*/
/* Make sure this is not direct access */
defined('_JEXEC') or die('Restricted access'),
/* Load the main controller */
require_once (JPATH_COMPONENT.DS.'controller.php'),
/* If controller variable is present, load component's controller. */
if($controller = JRequest::getVar('controller')) {
require_once (JPATH_COMPONENT . DS . 'controllers' .
DS.$controller . '.php'),
}
/* Create an instance of the controller */
$classname = 'HelloMVCcontroller'.ucfirst($controller);
$controller = new $classname( );
/* Execute the request */
$controller->execute(JRequest::getCmd('task'));
$controller->redirect();
?>Because of the MVC division, the design of the Model or code for the component does not have to be concerned with the presentation or user interface interaction with the Web visitor. That allows the core logic to be refined by professional developers separate from the categories of work traditionally associated with graphic artists and Web designers.
In this example View file, you can see the controller and interface portions of the extension addressed. Enter the following code, and save it as view.html.php in the hellomvcviewhellomvc folder:
<?php
/**
* @version $Id: hellomvc.php 7122 2007-06-21 11:52:29Z danr $
* @package hellomvc
*/
/* Make sure this is not direct access */
defined('_JEXEC') or die('Restricted access'),
/* Import the view class */
jimport( 'joomla.application.component.view'),
class HelloMvcViewHelloMvc extends JView
{
function display($tpl = null)
{
/* Display our greeting */
echo "<h1>Hello MVC!</h1>";
}
}
?>If possible, the View aspect of any component should adopt the presentation of the selected Joomla component. Thanks to the comprehensiveness of the Joomla core template CSS, there are a large number of stylesheet selections that can be cited through class or id references by the View interface. By adopting these stylesheets, the View presentation can be automatically synchronized with the styles chosen by the user through the current template.
The display() method is automatically called when a display request to the class is invoked. As you can see, it can be modified without affecting either the Model or the Controller.
Since the Controller does not handle any user interaction in this example, it must incorporate only the display() method to make the presentation. By calling the JController::display() method, most of the housekeeping for the presentation is handled automatically.
You will notice that this Controller functions under the observer pattern described earlier by extending the JController class. The code for the Controller should be saved in the site directory with a filename of controller.php:
<?php /** * @version $Id: hellomvc.php 7122 2007-06-21 11:52:29Z danr $ * @package hellomvc */ /* Make sure this is not direct access */
1defined('_JEXEC') or die('Restricted access'),
/* Import the controller class */
jimport('joomla.application.component.controller'),
/* Extend the JController class */
class HelloMVCcontroller extends JController
{
/* If request is for display of a view, call parent method
* so the view can be rendered.
*/
function display()
{
parent::display();
}
}
?>Once you address a menu to this component, the presentation will appear as if you used no design pattern within the implementation. However, when you attempt to upgrade the component or seek to further integrate the presentation of the component with the currently selected template, the advantages of using the MVC pattern will immediately become apparent. Instead of compromising the core code of the extension with special exceptions to follow the desired presentation, only the presentation layer will need to be modified, which will minimize potential execution errors.
Any changes to the basic algorithms held in the Model portion will not affect the layout. The layout may be custom-chosen by the client, but the developer of the core Model code will not have to worry about these considerations.
Even more encouraging, the interface can be freely expanded without jeopardizing the functioning of the application. The addition of such user interface niceties as a pop-up calendar or an interactive spell-checker will have no effect on the functioning of the core aspects of the component.
Enter the following code and save it as hellomvc.xml in the root of the component folder:
<?xml version="1.0" encoding="utf-8"?>
<install type="component" version="1.5.0">
<name>HelloMVC</name>
<version>1.5.0</version>
<description>Hello World example of an MVC component.</description>
<files>
<filename component="hellomv"c>hellomvc.php</filename>
<filename>index.html</filename>
<filename>controller.php</filename>
<filename>views/index.html</filename>
<filename>views/hellomvc/index.html</filename>
<filename>views/hellomvc/view.html.php</filename></files>
<administration>
<menu>HelloMVC</menu>
<files>
<filename component="hellomv"c>hellomvc.php</filename>
<filename>index.html</filename>
<filename>controller.php</filename>
<filename>views/index.html</filename>
<filename>views/hellomvc/index.html</filename>
<filename>views/hellomvc/view.html.php</filename>
</files>
</administration>
</install>Now, package the component in an archive named com_hellomvc.zip, and use the Extension Manager to install it into your Joomla system. If you connect a menu to reference the component and click on it, the greeting will been displayed as shown in Figure 8-2.
This is a very primitive example and only shows a glimmer of what can be accomplished using the MVC model. For example, the controllers and models folders were created but unused, since this component only had a single model and a single controller. Likewise, only a single view was placed in the views folder, whereas a standard component would have a different view for each task sent to it (such as displaylist, edit, newentry, and so on). Since the component has been stripped down to its very essence, you now understand the foundations of how this style of programming is performed.
If you now study the components that ship with the Joomla system (all of which use this structure), you will be able to adapt this Hello MVC implementation to nearly any type of component.
Design patterns have become increasingly important to developers as they face problems of increasing sophistication. By creating a documented library of successful implementation designs, the opportunity exists to minimize cost and schedule overruns that are common in the information technology industry.
More than ever, these patterns can be applied to subsystems such as extensions that are made to work with the Joomla framework. In this chapter, you learned how to apply design patterns by doing the following:
Understanding the Joomla implementation and object framework.
Using existing Joomla modules, components, and plug-ins to increase system capability.
Designing extensions that follow effective patterns for best-case implementation.
Evaluating existing system in terms of patterns so that the functionality of architectures such as Ajax could be understood within the evolution of networked systems.
Design patterns should help you to reuse the best methods of programming to develop any type of Joomla extension. In Chapter 9, you'll learn to create a plug-in that processes text for the Joomla system. For that plug-in, you will be able to see several of the patterns at work.