Work In Progress

This book is currently work in progress. Some sections are not yet written. Thank you for your understanding!

Dispatcher class

The Dispatcher is the "brains" of the module. Its getLayoutData method is called every time the module is rendered. It returns an array with the data which will be displayed by the view templates of the module.

A minimal implementation would look like this:


namespace Acme\Module\Example\Site\Dispatcher;

defined('_JEXEC') || die;

use Joomla\CMS\Dispatcher\AbstractModuleDispatcher;
use Joomla\CMS\Helper\HelperFactoryAwareInterface;
use Joomla\CMS\Helper\HelperFactoryAwareTrait;

class Dispatcher extends AbstractModuleDispatcher implements HelperFactoryAwareInterface
    use HelperFactoryAwareTrait;

    protected function getLayoutData()
        $data = parent::getLayoutData();

        $data['stuff'] = $this->getHelperFactory()
            ->getStuff($data['params'], $this->getApplication());

        return $data;

Let's focus on the overridden getLayoutData method.

We must always call the parent (overridden) method first. This gives us an array with very important bits of information needed to render the module:

  • module. The raw object with the module information as stored in the database.

  • app. The Joomla! application object. Do NOT assume it's always an instance of SiteApplication or AdministratorApplication; check!

  • input. The Joomla! input object. Use it wisely. If you are depending on request parameters for display of your module you need to consider how this affects caching, and whether having a component might be a better fit for your use case.

  • params. A Registry object with the module's parameters.

  • template. The name of the Joomla! template used to render the page. This is equivalent to calling \Joomla\CMS\Factory::getApplication()->getTemplate().

This data must always be present for Joomla! to successfully render a module. Therefore, we need to add to it. That's why we add a new key to the array before returning it.

We see that we call $this->getHelperFactory()->getHelper('ExampleHelper'). As you might have inferred, this tells Joomla to create an object instance of the ExampleHelper class in the module's helper namespace. As you may recall, we registered that namespace in our service provider. In the example plugin, the class we're asking Joomla to instantiate is Acme\Module\Example\Site\Helper\ExampleHelper.


We have to stress out that this is a major change from Joomla! 3.x and earlier. We no longer call static methods in the helper class. We have Joomla! create an object instance of that class and call its non-static method directly.

The method calls also shows a way to pass the module parameters to your helper object: by passing $data['params']. As noted above, the data element contains a Registry object with the module parameters.

The other thing you see in that method call is how you can pass the Joomla Application object to your helpers: by sending $this->app (or $data['app']) as an argument. This is preferred to going through the Joomla\CMS\Factory class as it makes Unit Testing of your module easier.

Even if you don't do any unit testing, it's always a good idea to inject dependencies (e.g. sending them as arguments, or otherwise setting them on the target object) instead of pulling dependencies by calling static methods. In practice, you will see that some core Joomla services, such as the UserFactory) are not readily available for injection, breaking this golden rule. This is something that's been actively worked on in Joomla!. Eventually, it will be possible to do dependency injection for all core services.

Needless to say, you can have more than one data keys for display in your module. Just remember, the $data array you return will be extracted into variables. Therefore, you must use array key names which are valid PHP variable names.