Easily modifying a page with Joomla! 1.5

Exclusive offer: get 50% off this eBook here
Mastering Joomla! 1.5 Extension and Framework Development

Mastering Joomla! 1.5 Extension and Framework Development — Save 50%

The Professional Guide to Programming Joomla!

$26.99    $13.50
by Chuck Lanham James Kennard | June 2010 | Joomla! Open Source

In addition to rendering the output of our extensions, we will often find it beneficial or even necessary to alter the normal flow by redirecting the browser to another page, or by customizing the generated document or page. Using a number of classes and libraries that Joomla! provides we can significantly enhance the user experience.

In this article by,Chuck Lanham and James Kennard, author of Mastering Joomla! 1.5 Extension and Framework Development,we will cover:

  • The application message queue and redirecting the browser
  • Session-level input validation
  • Modifying document properties specifically for our extensions

(Read more interesting articles on Joomla!1.5 here.)

Application message queue

You may have noticed that when we raise a notice or a warning, a bar appears across the top of the page containing the notice or warning message. These messages are part of the application message queue.

The application message queue is a message stack that is displayed the next time the application renders an HTML view. This means that we can queue messages in one request but not show them until a later request.

There are three core message types: message, notice, and error. The next screenshot depicts how each of the different types of application message is rendered:

Easily modifying a page with Joomla 1.5

We use the application enqueueMessage() method to add a message to the queue. This example demonstrates how we would add all of the messages shown in the previous screenshot to the message queue:

$mainframe->enqueueMessage('A message type message');
$mainframe->enqueueMessage('A notice type message', 'notice');
$mainframe->enqueueMessage('An error type message', 'error');

The first parameter is the message that we want to add and the second parameter is the message type; the default is message. It is uncommon to add notice or error messages this way; normally we will use JError::raiseNotice() and JError::raiseWarning() respectively.

This means that we will, in most cases, use one parameter with the enqueueMessage() method. It is possible however, to add messages of our own custom types. This is an example of how we would add a message of type bespoke:

$mainframe->enqueueMessage('A bespoke type message', 'bespoke');

Custom type messages will render in the same format as message type messages. Imagine we want to use the bespoke message type to render messages but not display them. This could be useful for debugging purposes.

This example demonstrates how we can add a CSS Declaration to the document, using the methods described earlier to modify the way in which the bespoke messages are displayed:

$css = '/* Bespoke Error Messages */
#system-message dt.bespoke
{
display: none;
}

dl#system-message dd.bespoke ul
{
color: #30A427;
border-top: 3px solid #94CA8D;
border-bottom: 3px solid #94CA8D;
background: #C8DEC7 url(notice-bespoke.png) 4px 4px no-repeat;
}';

$doc =& JFactory::getDocument();
$doc->addStyleDeclaration($css);

Now when bespoke messages are rendered, they will appear like this:

Easily modifying a page with Joomla 1.5

Redirecting the browser

Redirection allows us to redirect the browser to a new location. Joomla! provides us with some easy ways in which to redirect the browser.

Joomla! redirects are implemented using HTTP 301 redirect response codes. In the event that response headers have already been sent, JavaScript will be used to redirect the browser.

The most common time to redirect a browser is after a form has been submitted. There are a number of reasons why we might want to do this, such as the following:

  • Redirecting after form submission prevents forms from being submitted multiple times when the browser is refreshed
  • We can redirect to different locations depending on the submitted data
  • Redirecting to another view reduces the amount of development required for each task in the controller

There are many scenarios where the use of a redirect is common. The following list identifies some of these:

  • Canceling editing an existing item
  • Copying items
  • Creating new items and updating existing items
  • Deleting items
  • Publishing or unpublishing items
  • Updating item ordering

Imagine a user submits a form that is used to create a new record in a database table. The first thing we need to do when we receive a request of this type is to validate the form contents. This next data flow diagram describes the logic that we could implement:

Easily modifying a page with Joomla 1.5

The No route passes the invalid input to the session. We do this so that when we redirect the user to the input form we can repopulate the form with the invalid input. If we do not do this the user will have to complete the entire form again.

We may choose to omit the Pass invalid input to user session process as the core components do. It is normal to include JavaScript to validate forms before they are submitted, and since the majority of users will have JavaScript support enabled, this may be a good approach to use.

Note that omitting this process is not the same as omitting form validation. We must never depend on JavaScript or other client-side mechanisms for data validation. A good approach is to initially develop forms without client-side validation while ensuring that we properly handle invalid data with server-side scripts.

As a quick aside, a good way to validate form contents is to use a JTable subclass check() method.

If we place failed input into the session, we might want to put it in its own namespace. This makes it easier to remove the data later and helps prevent naming conflicts. The next example demonstrates how we might add the field value of myField to the myForm session namespace:

// get the session
$session =& JFactory::getSession();

// get the raw value of myField
$myFieldValue = JRequest::getString('myField', '', 'POST',
JREQUEST_ALLOWRAW);

// add the value to the session namespace myForm
$session->set('myField', $myFieldValue, 'myForm')

When we come to display the form we can retrieve the data from the session using the get() method. Once we have retrieved the data we must remember to remove the data from the session, otherwise it will be displayed every time we view the form (unless we use another flag as an indicator). We can remove data items from the myForm namespace using the clear() method:

// get the session
$session =& JFactory::getSession();

// Remove the myField
$session->clear('myField', 'myForm');

The final thing we do in the No route is to redirect the user back to the input form. When we do this, we must add some messages to the application queue to explain to the user why the input has been rejected.

The Yes route adds a new record to the database and then redirects the user to the newly created item. As with the No route, it is normal to queue a message that will say that the new item has been successfully saved, or something to that effect.

There are essentially two ways to redirect. The first is to use the application redirect() method.

It is unusual to use this mechanism unless we are developing a component without the use of the Joomla! MVC classes. This example demonstrates how we use the application method:

$mainframe->redirect('index.php?option=com_boxoffice');

This will redirect the user's browser to index.php?option=com_boxoffice. There are two additional optional parameters that we can provide when using this method. These are used to queue a message.

This example redirects us, as per the previous example, and queues a notice type message that will be displayed after the redirect has successfully completed:

$mainframe->redirect('index.php?option=com_boxoffice',
'Some Message', 'notice');

The final parameter, the message type, defaults to message.

The application redirect() method immediately queues the message, redirects the user's browser, and ends the application.

The more common mechanism for implementing redirects is to use the JController setRedirect() method. We generally use this from within a controller method that handles a task, but because the method is public we can use it outside of the controller.

This example, assuming we are within a JController subclass method, will set the controller redirect to index.php?option=com_boxoffice:

$this->setRedirect('index.php?option=com_boxoffice');

As with the application redirect() method, there are two additional optional parameters that we can provide when using this method. These are used to queue a message.

This example sets the controller redirect, as per the previous example, and queues a notice type message that will be displayed after the redirect has successfully completed:

$this->setRedirect('index.php?option=com_boxoffice', 'Some Message',
'notice');

Unlike the application redirect() method, this method does not immediately queue the optional message, redirect the user's browser, and end the application.To do this we must use the JController redirect() method.

It is normal, in components that use redirects, to execute the controller redirect() method after the controller has executed a given task. This is normally done in the root component file, as this example demonstrates:

$controller = new BoxofficeController();
$controller->execute(JRequest::getCmd('task'));
$controller->redirect();

Component XML metadata files and menu parameters

When we create menu items, if a component has a selection of views and layouts, we can choose which view and which layout we want to use. We can create an XML metadata file for each view and layout. In these files we can describe the view or layout and we can define extra parameters for the menu item specific to the specified layout.

Our component frontend has a single view with two layouts: default.php and list.php. The next figure describes the folder structure we would expect to find in the views folder (for simplicity, only the files and folders that we are discussing are included in the figure):

Easily modifying a page with Joomla 1.5

When an administrator creates a link to this view, the options displayed will not give any information beyond the names of the folders and files described above, as the next screenshot demonstrates:

Easily modifying a page with Joomla 1.5

The first element of this list that we will customize is the view name, Revue. To do this we must create a file in the revue folder called metadata.xml. This example customizes the name and description of the revue view:

?xml version="1.0" encoding="utf-8"?>
<metadata>
<view title="Movie Revues">
<message>
<![CDATA[Movie Revues]]>
</message>
</view>
</metadata>

Now if an administrator were to view the list of menu item types, Revue would be replaced with the text Movie Revues as defined in the view tag title attribute. The description, defined in the message tag, is displayed when the mouse cursor is over the view name.

The next task is to customize the definitions of the layouts, default.php and list.php.

Layout XML metadata files are located in the tmpl folder and are named the same as the corresponding layout template file. For example, the XML metadata file for default.php would be named default.xml.

So we need to add the files default.xml and list.xml to the tmpl folder.

Within a layout XML metadata file, there are two main tags in which we are interested: layout and state. Here is an example of a XML metadata file

<?xml version="1.0" encoding="utf-8"?>
<metadata>
<layout title="Individual Revue">
<message>
<![CDATA[Individual movie revue.]]>
</message>
</layout>
<state>
<name>Individual Revue</name>
<description>Individual movie revue.</description>
</state>
</metadata>

And here is the list.xml file:

<?xml version="1.0" encoding="utf-8"?>
<metadata>
<layout title="Revue List">
<message>
<![CDATA[Summary list of revues.]]>
</message>
</layout>
<state>
<name>Revue List</name>
<description>Summary list of revues.</description>
</state>
</metadata>

At first glance it may seem odd that we appear to be duplicating information in the layout and state tags. However, the layout tag includes information that is displayed in the menu item type list (essentially an overview). The state tag includes information that is displayed during the creation of a menu item that uses the layout.

There are occasions when a more detailed description is required when we come to define a menu item. For example, we may want to warn the user that they must fill in a specific menu parameter. We will discuss menu parameters in a moment.

Assuming we created the default.xml and list.xml files as shown previously, our menu item type list would now appear as follows:

Easily modifying a page with Joomla 1.5

Now that we know how to modify the names and descriptions of views and layouts, we can investigate how to define custom menu parameters.

There are many different types of parameter that we can define. Before you continue, you might want to familiarize yourself with this list of parameter types because we will be using them in the examples. A complete description of these parameters is available in Appendix B, Parameters (Core Elements):

  • category
  • editors
  • filelist
  • folderlist
  • helpsites
  • hidden
  • imagelist
  • languages
  • list
  • menu
  • menuitem
  • password
  • radio
  • section
  • spacer
  • sql
  • text
  • textarea
  • timezones

Menu parameters can be considered as being grouped into several categories:

  • System
  • Component
  • State
  • URL
  • Advanced

The System parameters are predefined by Joomla! (held in the administrator/components/com_menus/models/metadata/component.xml file). These parameters are used to encourage standardization of some common component parameters. System parameters are shown under the heading Parameters (System); we cannot prevent these parameters from being displayed.

The Component parameters are those parameters that are defined in the component's config.xml file. Note that changing these parameters when creating a new menu item only affects the menu item, not the entire component. In essence, this is a form of overriding.

This form of overriding is not always desirable; it is possible to prevent the component parameters from being shown when creating or editing a menu item. To do this we add the attribute menu to the root tag (config) of the component config.xml file and set the value of the attribute to hide:

The remaining parameter groups—State, URL, and Advanced—are defined on a per layout basis in the layout XML metadata files inside the state tag. These are the groups in which we are most interested.

The State parameters are located in a tag called params. In this example, which builds on our list.xml file, we add two parameters: a text field named revue_heading and a radio option named show_heading:

<?xml version="1.0" encoding="utf-8"?>
<metadata>
<layout title="Revue List">
<message>
<![CDATA[Summary list of revues.]]>
</message>
</layout>
<state>
<name>Revue List</name>
<description>Summary list of revues.</description>
<params>
<param type="radio" name="show_heading"
label="Show Heading"
description="Display heading above revues."
default="0">
<option value="0">Hide</option>
<option value="1">Show</option>
</param>
<param type="text" name="revue_heading"
label="Revue Heading"
description="Heading to display above the revues."
default="Box Office Revues" />
</params>
</state>
</metadata>

When an administrator creates a new menu item for this layout, these two parameters will be displayed under the heading Parameters (Basic).

The parameters are not presented under a State heading, because State and URL parameters are consolidated into one section. URL parameters always appear above State parameters.

We define URL parameters in much the same way, only this time we place them in a tag named url. The URL parameters are automatically appended to the URI; this means that we can access these parameters using JRequest.

These parameters are of particular use when we are creating a layout that is used to display a single item that is retrieved using a unique ID. If we use these parameters to define an ID that is retrieved from a table, we should consider using the often overlooked sql parameter type.

The following example builds on the previous example, and adds the URL parameter id, which is extracted from the #__boxoffice_revues table:

<?xml version="1.0" encoding="utf-8"?>
<metadata>
<layout title="Revue List">
<message>
<![CDATA[Summary list of revues.]]>
</message>
</layout>
<state>
<name>Revue List</name>
<description>Summary list of revues.</description>
<url>
<param type="sql" name="id" label="Revue:"
description="Revue to display"
query="SELECT id AS value, title AS id
FROM #__boxoffice_revues" />
</url>
<params>
<param type="radio" name="show_heading"
label="Show Heading"
description="Display heading above revues."
default="0">
<option value="0">Hide</option>
<option value="1">Show</option>
</param>
<param type="text" name="revue_heading"
label="Revue Heading"
description="Heading to display above the revues."
default="Box Office Revues" />
</params>
</state>
</metadata>

The query might be slightly confusing if you are not familiar with the sql parameter type. The query must return two fields, value and id. value specifies the value of the parameter and id specifies the identifier displayed in the drop-down box that is displayed when the parameter is rendered.

When using the sql parameter type, if applicable, remember to include a WHERE clause to display only published or equivalent items.

The Advanced parameters are specifically for defining parameters that are more complex than the State parameters. These parameters are defined in the advanced tag.

This example adds an advanced parameter called advanced_setting:

<?xml version="1.0" encoding="utf-8"?>
<metadata>
<layout title="Revue List">
<message>
<![CDATA[Summary list of revues.]]>
</message>
</layout>
<state>
<name>Revue List</name>
<description>Summary list of revues.</description>
<url>
<param type="sql" name="id" label="Revue:"
description="Revue to display"
query="SELECT id AS value, title AS id
FROM #__boxoffice_revues" />
</url>
<params>
<param type="radio" name="show_heading"
label="Show Heading"
description="Display heading above revues."
default="0">
<option value="0">Hide</option>
<option value="1">Show</option>
</param>
<param type="text" name="revue_heading"
label="Revue Heading"
description="Heading to display above the revues."
default="Box Office Revues" />
</params>
<advanced>
<param type="radio" name="list_by_cat"
label="List by Genre"
description="List revues by genre."
default="0">
<option value="0">No</option>
<option value="1">Yes</option>
</param>
</advanced>
</state>
</metadata>

Advanced parameters will appear under the Parameters Advanced heading. Component parameters, Component Design—will appear under the Parameters (Component) heading.

The resultant parameters area for this layout will appear as follows:

Easily modifying a page with Joomla 1.5

All name and description elements from the XML metadata files will be translated into the currently selected locale language.

When we save a menu item, all of the parameters, except URL parameters, are saved to the params field in the menu item record. This means that we can end up with naming conflicts between our parameters. We must ensure that we do not name any two parameters the same. This includes not using the predefined System parameter names.

This list details the System parameter names:

  • page_title
  • show_page_title
  • pageclass_sfx
  • menu_image
  • secure

Once we have successfully created the necessary XML, we will be able to access the parameters from within our component using a JParameter object. This is described in the next section.

Mastering Joomla! 1.5 Extension and Framework Development The Professional Guide to Programming Joomla!
Published: November 2007
eBook Price: $26.99
Book Price: $49.99
See more
Select your format and quantity:

(Read more interesting articles on Joomla!1.5  here.)

Using menu item parameters

Before we jump in and start using menu item parameters, let us take a moment to consider the overriding effects of the component parameters.

A second set of component parameters are saved to the menu item when we save it. This means that the component parameters are saved as part of the menu item, not the component. This allows a component, which can be installed only once, to be linked to the menu multiple times using different settings.

This raises the question: What is the purpose of the component preferences button in the backend? The preferences button, used to save the component settings, is used to modify the default component settings.

The default settings are used when we create a new menu item as the initial component parameter values. They are also used if the component is invoked but the active menu item does not correspond to the invoked component.

Consider the link index.php?option=com_boxoffice. This link will invoke the com_boxoffice component, but because no menu item is specified, the active menu item will be the first menu item in the main menu.

Now consider the link index.php?Itemid=53&option=com_boxoffice. This link will invoke the com_boxoffice component, but because the menu item is specified, the active menu item will be menu item 53. Assuming this menu item is for the corresponding component, then the component parameters saved to the menu item will be used.

In order to access the page parameters there is a useful method in the application, getPageParameters().

This method returns a JParameter object that is loaded with the component and menu item parameters. The menu item parameters always take precedence over the component parameters. For example, if both the component and the menu item defined a parameter show_title, the value recorded by the menu item would be the value that would be used in the JParameter object.

It is common to use this method in the display() method of JView sub-classes and assign the resultant object to the view for use by the layout. This example demonstrates how we can do this:

$params =& $mainframe->getPageParameters();
$this->assignRef('params', $params);

We can then use params as an attribute in our template files. This example demonstrates how we can check the value of the show_title parameter before proceeding to show the title:

<?php if ($this->params->get('show_title')) : ?>
<div id="revue_title">
<?php echo $this->title; ?>
</div>
<?php endif; ?>

It is generally easier when developing templates to include all possible elements. Once this is complete, it is generally easier to add the necessary parameters and make each element optional.

Modifying the document

The document, Getting Started, is a buffer used to store the content of the document that will be returned when a request is complete. There are a number of different things that we can modify in the document that will customize the resultant page.

Whenever we want to modify the document, we use the JFactory class to obtain a reference to the global document object. This example demonstrates how:

$document =& JFactory::getDocument();

Notice that we use the =& assignment operator to obtain a reference. If we do not, any modification we make to the document will not be applied.

All of the following examples in this section assume that $document is the global document object.

Page Title

The page title is the most commonly modified part of the page. The title is the contents of the title tag that is located in the XHTML head tag.

There are two methods related to the title: getTitle() and setTitle(). The getTitle() method retrieves the existing title and setTitle() sets the title to a new value.

This example demonstrates how we use setTitle() to make the title Some Exciting Title.

$document->setTitle(JText::_('Some Exciting Title'));

Notice that we use JText to translate the title before passing it. This is because the method does not translate new titles for us.

We never have to set the document title. If we don't, the site name will be used.

It is common practice to use the two methods together in order to append additional title information. Here is an example:

$title = $document->getTitle().' - '.JText::_('Some Exciting Title')
$document->setTitle($title);

Pathway

The pathway, also known as the breadcrumb (trail), describes to the user their current navigational position in a website. This is an example of a pathway for a menu item named 'Joomla! Overview':

Easily modifying a page with Joomla 1.5

Joomla! handles the pathway to the depth of the menu item. Beyond that we must manually add items to the breadcrumb. For example, a component that handles categories and multiple items will generally add to the pathway in order to display its internal hierarchy.

The pathway is handled by a global JPathway object. We can access the object using the application. The next example demonstrates how we obtain a reference to the breadcrumb handler:

$pathway =& $mainframe->getPathway();

Notice that, as usual, we must use the =& assignment operator to obtain a reference. If we do not, any changes we make to $pathway will not be reflected.

We use the addItem() method to add new items to the pathway. Imagine we are viewing a category in a component and we want to add the category as an extra layer in the pathway trail, as in this example:

$pathway->addItem($categoryName);

There is one glaringly obvious thing missing from this example. There is no URI. Since we are viewing the category, there is no need to specify the URI because it is the current URI.

The last item in the pathway is never a link. We only need to specify a URI when we add items that are not going to be the last item in the pathway. This example demonstrates how we might build the pathway for an item within the aforementioned category:

$pathway->addItem($categoryName, $categoryURI);
$pathway->addItem($itemName);

Notice this time we include a URI when adding the category item. It is normal b to add to the pathway in the display() method of each JView class. It is important to realize that we must always add pathway items in order of appearance.

There is one pitfall to the currently explained way of adding items to the pathway. It is likely that in the described scenario, we would be able to create a menu item that links directly to a category or item in the component.

We can overcome this by interrogating the current menu item. This example shows how we get access to the current menu item:

$menus =& JMenu::getInstance();
$menuitem =& $menus->getActive();

The JMenu class is responsible for the handling of Joomla! menus. The getActive() method returns a reference to the currently selected menu item object. This object is a stdClass object that contains various attributes that relate to the menu item.

The attribute that we are interested in is query. This attribute is an associative array that describes the URI query associated with the menu item. So to enhance our category pathway we would do this:

if ($menuitem->query['view'] != 'category')
{
$pathway =& $mainframe->getPathWay();
$pathway->addItem($categoryName);
}

The view key is the layout that the menu item is set to view.

To improve our pathway when viewing an item we can build on this example by adding a switch statement:

if ($menuitem->query['view'] != 'item')
{
$pathway =& $mainframe->getPathWay();
switch ($menuitem->query['view'])
{
case 'categories':
$pathway->addItem($categoryName, $categoryURI);
default:
$pathway->addItem($itemName);
}
}

We now have the ability to build the pathway from the point at which the menu item enters the component.

By using a switch statement without any breaks we make the building of the pathway extremely versatile. It would be very easy for us to add an extra hierarchical layer to the pathway based on this.

JavaScript

In order to add JavaScript cleanly it should be added to the document header. We can use the following methods to add JavaScript in this way:

  • The addScript() method is used to add a link to an external JavaScript file. This is an example of how to use the addScript() method:

    $js = JURI::base().'components/com_boxoffice/assets/script.js';
    $document->addScript($js);

  • The addScriptDeclaration() method is similar; it allows us to add RAW JavaScript to the header. This is an example of how to use the addScriptDeclaration() method:

    $js = 'function notify(text) { alert(text); }';
    $document->addScriptDeclaration($js);

We can use these two methods for any type of script. If we want to use script other than JavaScript, we can supply a second parameter defining the script MIME type. For example, if we wanted to use Visual Basic Script we would specify the MIME type text/vbscript.

CSS

In order to add CSS styles cleanly they should be added to the document header. We can use the methods addStyleSheet() and addStyleDeclaration() to add CSS.

addStyleSheet() is used to add a link to an external CSS file. This is an example of how to use the addStyleSheet() method:

$css = JURI::base().'components/com_foobar/assets/style.css';
$document =& JFactory::getDocument();
$document->addStyleSheet($css);

The nice thing about using this method is we can also specify the media type to which the styles apply. Imagine we have a special CSS file that is intended to format a document when we come to print. To achieve this we can specify the media type print:

$document->addStyleSheet($css, 'text/css', 'print');

Notice that the second parameter is text/css; this parameter is used to identify the MIME type and is used in the same way as it is in the addScript() and addScriptDeclaration() methods.

The third parameter is the media type, in this case print. This is a list of the CSS2 recognized media types:

  • all
  • aural
  • braille
  • embossed
  • handheld
  • print
  • projection
  • screen
  • tty

For more information about CSS media types please refer to the official documentation available at http://www.w3.org/TR/1998/REC-CSS2-19980512/media.html.

The addStyleDeclaration() method allows us to add RAW CSS styles to the header. This is an example of how to use the addStyleDeclaration() method:

$css = '.somestyle { padding: 10px; }';
$document->addStyleDeclaration($css);

Metadata

Metadata tags are used to help describe a document. There are two different types of metadata: http-equiv and non http-equiv. Metadata that is http-equiv is used to determine metadata to be used as HTTP header data.

There are two metadata methods in the document:

  • getMetaData(): This is used to retrieve the document metadata
  • setMetaData(): This is used to add metadata to the document

When we create extensions that handle information that we want search engines to index, it is important to add metadata to the document. This example adds some keywords metadata:

$keywords = 'monkey, ape, chimpanzee, gorilla, orang-utan';
$document->setMetaData('keywords', $keywords);

Adding http-equiv metadata is very similar. Imagine we want to turn off browser theme styling. We can use the http-equiv metadata type MSTHEMECOMPATIBLE:

$document->setMetaData('MSTHEMECOMPATIBLE', 'no', true);

It is that final parameter, when set to true, which tells the method that the metadata is http-equiv.

The getMetaData() method works in much the same way, except we retrieve values. Suppose that we wish to append some keywords to the document:

$keywords = explode(',', $document->getMetaData('keywords'));
$keywords[] = 'append me';
$keywords[] = 'and me';
$document->setMetaData('keywords', implode(',', $keywords));

This retrieves the existing keywords and explodes them into an array; this ensures we maintain the keyword comma separators. We proceed to add some new keywords to the array. Finally, we implode the array and reset the keywords metadata.

Custom header tags

If we want to add a different type of tag, not a script, CSS, or metadata, we can use the addCustomTag() method. This method allows us to inject code directly into a document header.

Imagine we want to add a comment to the document header:

$comment = '<!-- Oi, stop looking at my page source! :p -->';
$document->addCustomTag($comment);

Summary

In this article, we will cover:

  • The application message queue and redirecting the browser
  • Session-level input validation
  • Modifying document properties specifically for our extensions

If you have read this article you may be interested to view:

Mastering Joomla! 1.5 Extension and Framework Development The Professional Guide to Programming Joomla!
Published: November 2007
eBook Price: $26.99
Book Price: $49.99
See more
Select your format and quantity:

About the Author :


Chuck Lanham

Chuck Lanham began his career as a database software engineer with Burroughs Corp. He later worked for Informix Corp. managing the database tools development group while serving as repository architect. He has founded and managed two successful software development companies, and taught college courses on database theory, data communications, and computer technologies. He has also managed the global development and deployment of leading CRM and CMS systems for many Fortune 500 companies, and managed the development and deployment of some of the largest e-commerce websites in the world.

In 2002, Chuck left the corporate world and started a new company, Blue Water Associates. This company is located near the deep blue waters of Lake Tahoe where he designs, develops, and maintains websites for small to medium sized businesses, both within the U.S. and abroad.

Chuck has been developing websites using Joomla! since 2007 with the release of version 1.5 and has developed several extensions for use in the websites he has designed. This is Chuck's first book as an author, although he has reviewed and edited several books and written numerous technical articles for publication.

James Kennard

James Kennard is a computer programmer. He has worked with various PHP and MySQL applications, since 2002. He quickly discovered Mambo/Joomla! because of its flexible extension manager. James currently maintains one open-source Joomla! component, which has been translated into over fifteen languages. Moreover, he has plans to build two more open-source components. Examples of his work can be found on his personal website www.webamoeba.co.uk.

Books From Packt


Joomla! 1.5 SEO
Joomla! 1.5 SEO

Joomla! 1.5: Beginner's Guide
Joomla! 1.5: Beginner's Guide

Joomla! E-Commerce with VirtueMart
Joomla! E-Commerce with VirtueMart

Joomla! 1.5 Multimedia
Joomla! 1.5 Multimedia

Joomla! 1.5 Content Administration
Joomla! 1.5 Content Administration

Learning Joomla! 1.5 Extension Development
Learning Joomla! 1.5 Extension Development

Joomla! with Flash
Joomla! with Flash

Joomla! Web Security
Joomla! Web Security


Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software