MethodBuilder !

Mais qu'est-ce donc ?

Pour expliquer le principe du "MethodBuilder ", il faut expliquer le principe de la construction des "Components".

Pour construire un "Component", on prend une définition, c'est à dire tout simplement une map Javascript. Cette définition contient les méthodes que l'on souhaite voir intégré dans l'objet.

Un des avantages de maîtriser la construction de ses objets c'est qu'on a pour chaque méthode 2 informations :

• son nom
• la fonction que le développeur souhaite exécuter

Tout cela paraît bien basique, et pourtant ! Le nom décrit beaucoup de chose puisqu'il indique souvent le but d'une fonction. On peut donc apporter des services autour d'une méthode en se basant sur son nom.

Une propriété du javascript est qu'il est facile de faire une fonction "proxy" dans un objet, c'est-à -dire une fonction qui va englober la fonction d'origine, prendre les mêmes paramètres, lui transmettre, et manipuler le contexte pour faire croire à la fonction appelée qu'elle a été appelée directement (on force simplement le "this" à correspondre au "this" qu'on veut !).

Le MethodBuilder permet donc d'utiliser les conventions de nommage pour déterminer ce que l'on souhaite comme service pour une méthode.

Un MethodBuilder consiste donc en un objet composé d'une expression régulière, et d'une méthode de création de fonction.

En l'état, il y a 3 MethodBuilders :

• public&private : s'applique à toutes les méthodes. Les méthodes préfixées par '_' sont considérées comme privée et sont inaccessible via "objet.methode" mais le sont par "this.methode" dans l'objet
• listener : toute méthode préfixée par "on" est automatiquement inscrite sur le broker comme listener d'un évènement, dont le nom correspond à la suite du nom de la méthode. onHelloWorld sera donc appelée chaque fois que l'évènement "HelloWorld" sera levé.
• sender : toute méthode préfixée par "fire" sera automatiquement enregistrée comme fournisseuse d'évènement sur le broker dont le nom correspond à celui de la méthode privé "fire" (this.fireHelloWorld enverra un évènement HelloWorld, avec pour donné le premier argument passé en paramètre de la fonction). Actuellement la fonction d'origine décrite dans la définition du composant n'est pas utilisée, et est remplacée par une fonction envoyant l'évènement. Il est probable que la fonction d'origine soit appelée après l'envoi de l'évènement dans un futur proche.

Le MethodBuilder permet donc d'exécuter un travail transversal sur les objets. Le prochain MethodBuilder que je souhaite fabriquer est un logger par composant dont le rendu et la verbosité sera définie par défaut dans la définition de l'objet, et surchargeable par configuration (bref, l'idée est d'avoir un vrai "Log4JS" permettant de définir la méthode d'affichage et le niveau d'information à afficher suivant l'objet, voire même sa méthode).
Un autre avantage de ce système est qu'il permet au logger de connaître le nom de la méthode et de l'objet dans lequel il travaille, et ainsi de les indiquer lors du log (comme peut le faire Log4J d'ailleurs).

Actuellement, tous les MethodBuilders sont appliqués à tous les Components. L'amélioration de ce concept est de faire un système de configuration permettant d'activer/de désactiver des MethodBuilders suivant le Component, intégrées dans la configuration de celui-ci (en même temps que les dépendances) et surchargeables via une configuration centralisée.

Bref, c'est prometteur, et ça devrait permettre beaucoup de services sympathiques :)