- Summing Up
Joomlatools extension templates expose unparalleled flexibility and power. What follows is a high level overview of the structures we use so that you can better understand what’s happening in each layout.
This file gets loaded following the same rules as regular Joomla layouts. Get some more details in Overrides
This is not a great deal of code, but there is a lot going on. In this template we are making use of Functions, Helpers, Special Tags and Partials. Joomlatools components use all of these to keep our templates compact, segmented and thus reusable.
Partials are a great way of separating layouts into manageable chunks. They are just template files, that can be loaded on their own, or included within another layout. We do this with the
import template function. You saw an example of this above with the line that looks like:
<?= is short for
<?php echo, which gets replaced when the template is compiled.
default_list.html in this case is the name of the template file itself without the
php file extension. The above method will attempt include a file called
default_name.html.php from the same directory in which the parent files reside
The template system also applies Template Overrides to partials.
import(), a second argument can be supplied to pass additional variables to the included partial. For example:
This will create a variable in the partial called
$title with a value of
This is my list in the imported template. In addition, any variables that exist in the parent layout will be automatically be passed through to the partial.
The Framework comes packaged with several helpers, including but not limited to:
- Actionbar: gathers and renders all the parts of the administrator application action bar for a given component (title and commands).
- Date: date helper functions, including formatting and humanizing dates (e.g. 1 minute ago).
- Debug: if JConfig ‘debug’ is enabled, this will provide some nicely formatted information
- Editor: render
editorfor a given editable text field
triggermethod to fire a plugin event
- Grid: grid table controls, including checkbox, search, enable/disable, order, and access.
- Listbox: allows you to create a select list or auto-complete from data returned from a model.
- Menubar: gathers and renders all the parts of the administrator application menu bar for a given component (sub-menu links).
Helpers are invoked using the
helper template function. That function can take two arguments and a example could look something like:
The first argument is a required string that is the helper’s Object Identifier with a method name concatenated on the end with a period
To rephrase, everything before the last period in the string is an Object Identifier and after, is a method that is in that helper object’s interface.
The second argument is an optional array of options that are relevant to the helper method.
Our example helper call looks for the following class and tries to fire the
bar method, while passing the array of options along.
If that class is not found the system looks for an appropriately named substitute in the
template/helper fallback hierarchy:
A helper identifier can take on the form of a fully qualified identifier as above, or a more convenient abbreviated form where just the file name of the helper is used with the concatenated method. Hence, if we are working on a template in
com_acme the following command will produce the same result as the previous example:
The template engine assumes that the helper’s identifier is
In this case the system assumes that your helper classes are located somewhere in the
template/helper fallback hierarchy:
In our example template in the introduction you saw us use this line of code in our example:
That call looks for the
listbox helper and tries to invoke the
category_id method of its interface. If there is not a
com_acme/template/helper/listbox.php the system will load
libraries/joomlatools/component/koowa/template/helper/listbox.php instead and then pass along the array of configuration options to the method.
There are a number of ‘core’ template functions of which our extensions make use. We’ve already introduced
import above. Template functions let us shorten what can be lengthy object method calls, alias more obscure function names and generally help keep the layouts clean.
Here are some of the mappings:
When a Joomlatools layout gets compiled the above mappings are applied and the corresponding calls evaluated. What that means for example is that calling
object() inside a template file is the same as calling
Tags are one more important part of the template dialect that Joomlatools uses. The engine finds the
title in a template, filters them out, and adds them to the head document. The
script tags can optionally be given the
data-inline attribute, which lets them stay exactly where there are in the layout.
ktml namespace tags (i.e.
<ktml:toolbar></ktml:toolbar>) also get filtered and replaced with specialized dynamic output. We use the
ktml namespace to avoid name collisions with other tags.
<ktml:script src=[url]>- Render a script tag with specified source url and place that tag in the head.
<ktml:style src=[url]>- Render the appropriate
src, and add it to the head.
<ktml:module position=[position]>- Take the content contained inside the tag, and inject it into the specified module
<ktml:toolbar>- Find the controller toolbar which is currently active and render its output. Often used inside a
<ktml:content>- Gets the currently rendered content from the template object. Allows the current layout to
decoratethat content, and replace it back into the template object.
<ktml:message>- Render the response flash messages.
You may also see special scheme information in the URLs that our templates use to load resources. For URLs in a layout that follow this form, Joomlatools relies on the use of another filter that replaces them with the appropriate
http:// scheme, relevant domain and path information for that resource.
media:// scheme specification, gets replaced with the current URL for the media directory, i.e.
http://joomla.box/media/. In combination with the
ktml:script tag, the final result gets added to the head in the form:
root:// url schemes which load the
base url and
root url of your application, respectively.
If enabled, this filter will run at the beginning of rendering, before the Assets filter is run. It finds all those
media:// urls we were just talking about and provides a
versioned fingerprinting of the file url, based on the version of the component. This ensures that the right version of the media file gets cached in the client browser.
<ktml:script src="media://com_acme/js/foo.js" />
gets updated to
<ktml:script src="media://com_acme/js/foo.js?c81e728d" />
This filter feeds information from JDocument into the template to be used in page rendering. It is a special case, because it will only run when we want to bypass the application template, for example in a modal.
This is a Module focused filter. When a Joomlatools module is rendered, this filter allows for an appropriate
chrome style to be applied to the module content.
The framework provides some handy shortcuts and syntactical sugar for use in our view templates. They help keep templates clean and function names more relevant.
Here are some of them:
translate shortcut to translate a string:
helper shortcut to load the
date.humanize helper to make date information easier to read for us humans:
route shortcut to build the URL to the singular view:
We’ve taken a high level look at the Joomlatools template system. With a solid understanding of these fundamental pieces you can easily gain insight into what’s happening in those templates. More importantly, you can also customize all of the Joomlatools extensions and add information that you want to see.
Let our developers personally assist you. You can ask development related questions in our Support Center. Only for Business or Agency subscribers.
- Getting Started
- Digging Deeper