From the Rough Cut
From the Rough Cut
From the Rough Cut
Global Objects
Some of the objects in Joomla are used in so many places in the code that it makes sense to have them be readily available at all times. The "JFactory" class ("libraries/joomla/factory.php"), as mentioned earlier, is loaded when the "includes/framework.php" script loads the "libraries/joomla/import.php" script.
"JFactory" give us quick access to a number of objects at almost any point in the program. These are listed in the table below.
|
Object Type |
Description |
Code to Access |
|
JApplication / JSite / JAdministrator |
Application object. JSite when in the front end, JAdministrator when in the back end. |
$app = JFactory::getApplication; |
|
JRegistry |
configuration.php file values in form of JRegistry object. |
$config = JFactory::getConfig(); |
|
JSession |
Current session. |
$session = JFactory::getSession(); |
|
JLanguage |
Language object. |
$language = JFactory::getLanguage(); |
|
JDocument, JDocumentHTML, JDocumentFeed, JDocumentJSON |
Current document. |
$document = JFactory::getDocument(); |
|
JUser |
Current user. |
$user = JFactory::getUser(); |
|
JAccess |
Current access object (used in access control). |
$access = JFactory::getACL(); |
|
JDatabase |
Database object used for running queries. |
$dbo = JFactory::getDbo(); |
|
JMail |
Mailer object for sending emails from the site. |
$mail = JFactory::getMailer(); |
|
JXMLElement |
XML element. |
$xml = JFactory::getXML($pathToXml) |
|
JEditor |
Editor object. |
$editor = JFactory::getEditor(); |
|
JURI |
URI object. |
$uri = JFactory::getUri(); |
|
JDate |
Date / time object. |
$date = JFactory::getDate(); |
Figure 45: Global Objects Table
Except for "JDate", each of these classes should only have one object for that class. For example, there should only one application object, "JSite" if you are in the front end and JAdministrator if you in the back end. Similarly, there should only be one "JSession", "JUser", "JDatabase" and so on.
In object-oriented programming, when we have a situation like this, we often use what is called the "singleton" and "factory" design patterns to ensure that we only have one object of a given type in existence at one time. The way it works is actually very simple.
Let's look at an example of how this works using the application object. The JFactory class contains a field called $application that stores the one application object we want to use for this entire execution cycle. When we need the application object, we use the command JFactory::getApplication().
When we do that command, JFactory first checks to see if there is already an object in the $application field. If so, it just returns that object. If the $application field is empty, it means this is the first time in this cycle that we have tried to access it. In this case, we create the new application object, store it in the $application field in the JFactory class, and then we return the $application field. That way, it is in the JFactory class field the next time we need it. So we ensure that we only create one application object and that it is available whenever we need it.
Please see Appendix B for more information on the "singleton" and "factory" design patterns and how they are used in Joomla.