Posts tagged with joomla 1.5

Joomla! 1.5 – Generating raw ouput

Can anybody tell me how Joomla! 1.5 will be able to give just raw output so I can generate XML or JSON for my dynamic pages?

This is a common question for developers that are diving a bit deeper into Joomla! 1.5 and want to integrate AJAX functionality into their extensions. They quickly find that index.php always generates code within the XHTML-template and thats not what they need. Instead they want to generate XML for evaluating in JavaScript without any XHTML wrapped around it. Sounds familiar ? Well, here is how you can do this with Joomla! 1.5.

An introduction into JDocument

Before we dive into the actual solution we need to talk a bit about JDocument first. JDocument is a completely new framework API that allows developers to render different types of output. JDocument is a very flexible library that handles the loading and rendering of your templates and is made up out of formats and renderers.

Format

A format is the type of document that gets created, for 1.5 the supported formats are html (default), pdf, feed, error and raw.

Renderer

A renderer is responsible for creating the actual output. It can be triggered by a function call or by a placeholder. For example, the html format has renderers for a module, modules, component, head and message. These renderers are triggered by the placeholders in the template files. Like :


The above piece of code will load the all modules assigned to the footer position and wrap them in an xhtml module style.

The feed format on the other hand has renderers for atom1.0 and rss2.0. These renderers are called by specifying the type of renderer in the url of by passing the type to the JDocument constructor.

For example, the following URL will display the rss feeds for the FAQ’s category :

index.php?option=com_content&view=section&id=3&format=feed&type=rss

or with search engine friendly url’s on this becomes :

index.php/faq.feed?type=rss

The JDocument library is very flexible and powerfull. It would take a whole tutorial to explain how to leverage all the power, for now i’ll just stick to explaining how to use it to render only the component and how to render without any html output.

Rendering only the component

Old way Joomla! 1.0 : index2.php and index3.php where used to only output the component without any modules. These two files have been deprecated in Joomla! 1.5. There are only in the package to maintain backwards compatibility and should not be used anymore when developing new extensions.

New way Joomla! 1.5 : index.php?option=com_mycomponent&tmpl=component

How does this work ?

When you render only the component you are loading a special layout file that doesn’t has placeholders for any of the modules. This is exactly what happens here.

The ‘tmpl’ variable, refers to the name of the template file that is being loaded by JDocumentHTML. Instead of loading the ‘index.php’ template (the default layout) JDocumentHTML loads the component.html layout .(You can find the file in templates/_system/component.html.) If you examine this template file closely you will notice that it only renders the component.

Tips and tricks

you can override the _system layouts in your own templates, simply copy the file in your own template root directory and the system will use them instead of the default ones. This allows you to easily style the offline, error, … pages Joomla! 1.5 outputs.

Rendering only the raw component output

Old way Joomla! 1.0 : index.php?option=com_mycomponent&no_html=1

New way Joomla! 1.5 : index.php?option=com_mycomponent&format=raw

How does this work ?

What happens is you are now telling the system to use a different output format called ‘raw’ instead of ‘html’ the default one. The system will load the JDocumentRAW output format to render the document and will only output whatever the component creates.

Tips and tricks

You can use the ‘format’ specifier to make the system use the feed format. The feed format has a renderer for Atom1.0 and RSS2.0. All you need to do is give JDocument the necessary info to create the feed and he will do the rest, allowing you to easily switch between Atom and RSS output.

There is alot more that this baby can do, in a next blog post I’ll try to dive into some of the more advanced uses of JDocument. Have fun coding !

By the way: I’m blogging live from the Joomlatools Doccamp in Brussels!

Joomla! will reach turning point in March 2008.

At the end of 2007 Joomla! passed the 2.5 million download mark, which went by quite silently.

At the moment Joomla! is already on it’s way to the 3 million mark, which will likely be reached somewhere in february.

If you wanna track total downloads for the top 10 Joomla! extensions yourself you can easily do this by checking out the front page on Joomlacode.org. At the right side you will find a small overview of the top 10 projects, ranked by total downloads.

You will notice that our own DOCman is currently listed at 5th place with a total of 300.000 downloads.

Joomlacode has a very nice feature that allows you to create reports from different data sources. In my case I used it to get monthly download statistics for both Joomla! 1.0 and 1.5 in an effort to try and make a prediction about when Joomla! 1.5 will superseed 1.0. This resulted in the below graph.

Remarks :

  • There is no data available from before April 2007 because Joomlacode.org only opened it’s doors mid March 2007.
  • The data for January 2008 is extrapolated from the data available at the moment so it’s not a 100% but a good indication.
  • For October 2008 we are seeing a slightly higher amount of downloads for Joomla! 1.5, this is likely related to the release of Joomla! 1.5 RC3 beginning of that month.

Conclusions :

  • Joomla! 1.0 has been holding pretty steady at 200.000 downloads a month in 2007. Only from december we see a slight decline in downloads.
  • Joomla! 1.5 has slowly been increasing from 70.000 downloads in June towards 120.000 download a month in December.
  • Overall the introduction of 1.5 has increased the total amount of downloads each month from 200.000 for 1.0 only to 300.000 for both.

What does this tell us about the uptake of Joomla! 1.5 ? For that we need another graph that shows us the download percentage share for both :

Remarks :

  • The graph only shows the the percentage shares from the release of 1.5 RC1 and forward.
  • The graph shows a steady 5% increase of 1.5 downloads in regards to 1.0 from November 2007.

Based on this data I would dare to conclude that Joomla! 1.5 will superseed Joomla! 1.0 in March 2008. Exciting times ahead !

Joomla! 1.5 – Using JFactory and jimport() sensibly

David raised an interesting question in his very first post on the Joomla! forums, about using jimport() for classes that are deeply nested in the framework’s directory structure. The answer is simple: don’t load those classes. Problem solved! Right ?

Well, right, but why can’t you load them?

What is jimport?

Joomla!’s framework is located in /libraries/joomla. Instead of using require_once to load those files, you use the jimport() function. It uses a syntax with dots: to load /libraries/joomla/utilities/utility.php, you write jimport(‘joomla.utilities.utility’); The JUtility class is now available for you to use in your code.

jimport('joomla.utilities.utility');
echo JUtility::dump($myvar);
// dumps the contents of $myvar to the screen

The same thing goes for files that are nested deeper, like /libraries/joomla/application/component/view.php:

jimport('joomla.application.component.view');
class MycomponentViewItems extends JView
{ /* ... */ }

In J!1.5RC4, jimport got a little smarter. When using PHP5, instead of loading the file right away, the filename and the classname are registered, and loading is deferred until the class is actually needed. So when looking at our first example:

jimport('joomla.utilities.utility');
// at this point, utility.php is not yet loaded

echo JUtility::dump($myvar);
// when the JUtility class is needed, utility.php is loaded.

(This may look a little unnecessary: why not load the file right away, if we’re going to need it anyway? For now, let me just say that there are a number of scenario’s where this is a good idea, like in legacy mode. We’ll deal with those in another blog post.)

So what’s happening? jimport looks at the last part of the ‘joomla.utilities.utility’ string, adds a ‘J’ prefix, and registers the resulting ‘JUtility’ as the class name for utility.php. When you use JUtility, in the example above, or in MyClass extends JUtility, or in class_exists(‘JUtility’), the file utility.php is loaded.

The problem

David wonders in his post what happens when you want to use JSessionStorageDatabase, located in /libraries/joomla/session/storage/database.php. According to what I wrote above, you need to use jimport(‘joomla.session.storage.database’). However, this would register JDatabase as the classname, but in fact it should be JSessionStorageDatabase. Trying to use the class results in an error, because the file containing it isn’t being loaded. In reality, we never need to load classes like JSessionStorageDatabase in our code. Joomla! has factories for that.

About JFactory

Your code doesn’t have to worry about how to instantiate certain objects. The specifics are all handled by JFactory and a bunch of getInstance methods. Eg. JFactory::getDBO() might give you a JDatabaseMySQL object or a JDatabaseMySQLi object, or perhaps even a JDatabasePostgresSQL object in a later version. JFactory::getSession() gives you a JSession object. This object contains a JSessionStorage object, which can be JSessionStorageDatabase or JSessionStorageApc or any other. The point is: you don’t need to worry about it. JFactory (and JSession::getInstance(), JDatabase::getInstance(), …) take care of all that.

The only classes you need to use jimport for are classes with a single name like JFoo, not classes like JFooBar. And most importantly, always look at JFactory first, to see if you can get what you need there.

Optimize your Joomla! 1.5 component installer

Most developers know that a component can have an install.componentname.php, containing a com_install() function with your custom instructions. For example, copying files to different locations or inserting localized sample data. When these instructions fail, you can of course print a message about that. The result however, is that the user sees both your ‘Failed’ message, as well as Joomla!’s ‘Success’ message. Users find this is very confusing.

The solution is actually extemely simple: inside com_install(), you need to return false. This tells the installer that your custom script has failed, and a relevant error message will be displayed. There is an added benefit as well: the installer will perform a rollback, removing all the files in the process.

By the way: I’m blogging live from the Joomlatools Bug Squashing event in Brussels!