====== Jelix and the jCommunity module ======

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.

===== Presentation =====


**jCommunity is the management module of users for all kind of website**. 
It includes a complet workflow of management  :
  * Subscribe/Unsubscribe
  * Login/Logout

===== Overload of templates =====

**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 : 

  * [[https://bitbucket.org/laurentj/jcommunity/src/a3d8f46a36a4/modules/jcommunity/templates/fr_FR/account_show.tpl|jcommunity]]  (the original)
  * [[https://bitbucket.org/foxmask/havefnubb/src/tip/havefnubb/var/themes/default/jcommunity/account_show.tpl|havefnubb]] (the overload)


===== Dao 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 : 

  * [[https://bitbucket.org/laurentj/jcommunity/src/a3d8f46a36a4/modules/jcommunity/daos/user.dao.xml|jcommunity]] (the original)
  * [[https://bitbucket.org/foxmask/havefnubb/src/9262850763cd/havefnubb/var/overloads/jcommunity/daos/user.dao.xml|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 : 

  * [[https://bitbucket.org/laurentj/jcommunity/src/a3d8f46a36a4/modules/jcommunity/forms/account.form.xml|jcommunity]] (the original)
  * [[https://bitbucket.org/foxmask/havefnubb/src/9262850763cd/havefnubb/var/overloads/jcommunity/forms/account.form.xml|havefnubb]] (the overloaded)
 

===== Functionnal Extension of the module =====

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.
 ([[en:tutorials:modules:jevent|little reminder on Events Jelix in a previous article]] )

===== Conclusion =====
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.