In PHP, if an existing class or API you like but you want to bring your personal touch you include it and overloading to avoid touching it.

Exactly the same principle applies with Jelix modules. We then speak of “overload”.

A module is not a simple class (but composed of controllers, daos, forms, templates, zones, classes, translation files) not everything can be overloaded.

What can be overload ?

• The templates : to modify the render
• The Dao : to add the properties (column / tables) and the factories (access method of tables)
• The forms : to add the field of forms and the associated rules of control
• The locales : tanslation files

Advantages of the “Overload” :

• Extension of the fonctionnalities of the original module
• Suitability of all aspects of the module (exception for the controller)
• Ease of updating the original module, does not change any line of code in it

So take the module as a concrete example Jelix, jCommunity, and see what can be learned.

jCommunity is the management module of users for all kind of website. It includes a complet workflow of management :

• Subscribe/Unsubscribe
• Login/Logout

Question

Ok that's cool but I want to adapt the rendering templates jCommunity the themes of my site. how?

Answer

By default the name of the theme is default.

So to override a template will be placed just the modified version of it in the folder var/themes/default/jCommunity

So when Jelix call the template of the module, it will first see if a version exists in the theme folder and use it.

Compare : the template of the view page of the membre :

• jcommunity (the original)
• havefnubb (the overload)

Question

The table jCommunity does not contain enough of informations to manage my members, how to extend this one ?

Answer

Let's copy the Dao jcommunity/dao/user.dao.xml in the folder var/overload/jcommunity/daos

Let's change the content of what we need :

• name of the table and the new colums. New DAO methods etc.

like previously Jelix will go to see first if one existing DAO is in that folder.

All of this by respecting a least the name of the existing method in the original DAO.

Compare : Dao account.dao.xml :

• jcommunity (the original)
• havefnubb (the overloaded)

3) Overload of forms :

Question : The form managing the data of the users is too light for you ?

Answer :

Ok, let's make a copy of the forms jcommunity/forms/account.form.xml in the folder var/overload/jcommunity/forms Then we add the fields you need to see displayed (corresponding to our modified DAO).

Like previously Jelix will go to see first if one existing forms is in that folder.

Compare : the Forms account.forms.xml :

• jcommunity (the original)
• havefnubb (the overloaded)

Ok everything is running well

We could overload as we wish.

Remains a last detail, after the overload of the presentation layer,

We need to extend the functionnal layer.

And this is made possible by the events Jelix

for example, when a member is subscribing, I wish to check if this one is not banned from the site.

For that, jCommunity manage an event jcommunity_registration_prepare_save, send just before the email member. By responding to this event (wih the listener) we are able to proceed to the checking without returning to the jCommunity the respond, positive or not. (little reminder on Events Jelix in a previous article )

So, when the call of jCommunity, and with the differents orverload, this are your own ressource that are used, while fully exploiting the core/workflow jCommunity.