The Factory

The Factory object is used by FOF to create new instances of MVC objects: Dispatcher, Controller, Model, View, Toolbar, TransparentAuthentication as well as Form (the object used to manipulate XML forms) and ViewFinder (used to locate view template files) objects.

In essence, the Factory determines how much "magic" you want FOF to apply to your component. This comes in stark contrast with FOF 1.x/2.x where you were forced to accept the fact that FOF was trying too hard to find and create objects, even when you didn't mean it to.

Choosing your Factory

The Factory class which will be used by FOF for each component is defined in the Container using the factoryClass property when the Container is constructed. Please note that if you change it afterwards it will have no effect.

There are two ways to pass that parameter to the Container: as an initialisation value or through the fof.xml file.

In the first method you need to tell the Container which class to use when creating it. For example:

$container = FOF30\Container\Container::getInstance('com_example', array(
    'factoryClass' => 'MagicSwitch'
));

The drawback is that everyone who wants to call your component through HMVC needs to know which parameter to pass. Bad idea.

The best method is through fof.xml's <container> tag in the <common>, <backend> or <frontend> section.

Built-in Factory classes

FOF ships with a few different Factory classes for varying degrees of magic. Below we will see what each Factory class does.

BasicFactory

This is the default factory unless you specify otherwise.

• All your Controller, Model and View classes must be explicitly defined in their own class files. There is no magic class creation.
• fof.xml configuration for the Controller, Model and View is NOT taken into account.
• The classes are only looked for in the same application area (backend / frontend) as the one your component is currently executing in. Running under CLI is considered to be the same as running in the frontend.
• XML forms are only looked for in the same application area (backend / frontend) as the one your component is currently executing in.
• PHP and Blade view templates are looked for in the same application area (backend / frontend) as the one your component is currently executing in and only in the view explictly stated (FOF won't look in the pluralised/singularised view name).
• If a Dispatcher, Toolbar or TransparentAuthentication class is not found in your component one will be created for you. However, the fof.xml configuration will NOT be taken into account.

SwitchFactory

• All your Controller, Model and View classes must be explicitly defined in their own class files. There is no magic class creation.
• fof.xml configuration for the Controller, Model and View is NOT taken into account.
• The classes are looked for in both the backend and the frontend. The application area you are currently running in has priority.
• XML forms are looked for in both the backend and the frontend. The application area you are currently running in has priority.
• PHP and Blade view templates are looked for in both the front-end and back-end and in both the singularised/pluralised view name.
• If a Dispatcher, Toolbar or TransparentAuthentication class is not found in your component one will be created for you. However, the fof.xml configuration will NOT be taken into account.

MagicFactory

• If your Controller, Model and View classes are not defined a suitable DataController, DataModel/TreeModel and Html/Form view will be created automatically.
• If the class is created automatically, fof.xml configuration for the Controller, Model and View is taken into account.
• The classes are only looked for in the same application area (backend / frontend) as the one your component is currently executing in. Running under CLI is considered to be the same as running in the frontend.
• XML forms are only looked for in the same application area (backend / frontend) as the one your component is currently executing in.
• PHP and Blade view templates are looked for in the same application area (backend / frontend) as the one your component is currently executing in and only in the view explictly stated (FOF won't look in the pluralised/singularised view name).
• If a Dispatcher, Toolbar or TransparentAuthentication class is not found in your component one will be created for you. If the class is created automatically, fof.xml configuration will be taken into account.
• The fof.xml for Toolbar is always taken into account.

MagicSwitchFactory

This is equivalent to the FOF 1.x/2.x behaviour.

• If your Controller, Model and View classes are not defined a suitable DataController, DataModel/TreeModel and Html/Form view will be created automatically.
• If the class is created automatically, fof.xml configuration for the Controller, Model and View is taken into account.
• The classes are looked for in both the backend and the frontend. The application area you are currently running in has priority.
• XML forms are looked for in both the backend and the frontend. The application area you are currently running in has priority.
• PHP and Blade view templates are looked for in both the front-end and back-end and in both the singularised/pluralised view name.
• If a Dispatcher, Toolbar or TransparentAuthentication class is not found in your component one will be created for you. If the class is created automatically, fof.xml configuration will be taken into account.
• The fof.xml for Toolbar is always taken into account.

Unlike FOF 2.x, MagicSwitch doesn't work on Field or Behavior, only the Switch or Magic behaviour will apply (in this order)

Default MVC classes in the magic factories

The magic factories will always look for default MVC classes when creating a new Controller, Model, View, Dispatcher or TransparentAuthentication object. These are sought for under your component's namespace. Assuming your component namespace is Acme\Example\Admin the following default classes will be looked for.

Please remember that default classes will only be used by the magic factory if the class is not defined. If you have defined your class remember to extend from the default class yourself. For example:

class Items extends DefaultDataModel
{
    // ....
}

Controller

Class Acme\Example\Admin\Controller\DefaultDataController. It must extend FOF30\Controller\DataController.

If it's not found FOF will use FOF30\Controller\DataController.

Model

Class Acme\Example\Admin\Model\DefaultDataModel for simple data models. It must extend FOF30\Model\DataModel. Conversly, class Acme\Example\Admin\Model\DefaultTreeModel for nested set (tree) models. It must extend FOF30\Model\TreeModel.

If it's not found FOF will use FOF30\Model\DataModel or FOF30\Model\TreeModel respectively.

View

Class Acme\Example\Admin\View\DataView\DefaultViewtype where Viewtype is the view type, e.g. Html, Raw, Json, Csv and so on. It must implement FOF30\View\DataViewInterface.

If it's not found FOF will first try to find FOF30\View\DataView\Viewtype.

If that's also not found it will look for Acme\Example\Admin\View\DataView\DefaultHtml.

If this still doesn't exist, FOF will resort to FOF30\View\DataView\Html.

Dispatcher

Class Acme\Example\Admin\Dispatcher\DefaultDispatcher. It must extend FOF30\Dispatcher\Dispatcher.

If it's not found FOF will use FOF30\Dispatcher\Dispatcher.

Transparent Authentication

Class Acme\Example\Admin\TransparentAuthentication\DefaultTransparentAuthentication. It must extend FOF30\TransparentAuthentication\TransparentAuthentication.

If it's not found FOF will use FOF30\TransparentAuthentication\TransparentAuthentication.