L’architecture pr´esent´ee `a la section pr´ec´edente permet au d´eveloppeur de cr´eer un package en d´efinissant le mod`ele de donn´ees, les actions possibles sur l’objet, les affichages de l’objet et de l’interface, et enfin les interactions de saisie. L’h´eritage des packages offre une certaine flexibilit´e puisque le d´eveloppeur choisit les ´el´ements `a (re)d´efinir. Cependant, cela s’av`ere insuffisant. En effet, un d´eveloppeur peut avoir besoin d’utiliser un package pr´ed´efini dans le moteur de Sydonie et d’y apporter quelques modifications, sans pour autant vouloir cr´eer un package d´eriv´e. Le moteur du framework ´etant d´ecoupl´e de l’application, nous avons mis en place un m´ecanisme, que nous avons appel´e h´eritage en double cascade, permettant de r´ealiser cela. Nous pr´esentons celui-ci dans cette section.
7.3.1 Principe
L’architecture de packages permet la cr´eation de nouveaux types d’objets. Le d´eveloppeur peut d´evelopper des packages pour cr´eer des fonctionnalit´es n’existant pas encore dans le frame-work. Un des int´erˆets du framework est de pouvoir r´eutiliser des fonctionnalit´es existantes. Dans ce cadre, un d´eveloppeur peut souhaiter simplement adapter un package existant sans pour au-tant cr´eer un package d´eriv´e. Par exemple, le framework poss`ede un package Article pour g´erer les articles dans un site. Un d´eveloppeur qui souhaite utiliser ce type de document dans son application voudra certainement effectuer un certain nombre de≪r´eglages ≫. Par exemple, il veut adapter le mod`ele de l’objetArticle, en y ajoutant un attribut de ≪chapo ≫, modifier le template d’affichage pour l’adapter `a son site, modifier une fonctionnalit´e ou en ajouter une nouvelle. Pour permettre ces r´eglages fins et ajouter ainsi plus de souplesse de d´eveloppement, nous avons cr´e´e un m´ecanisme de ≪ double cascade ≫ qui tire parti du d´ecouplage entre le moteur du framework et les applications.
Grˆace `a ce m´ecanisme, le d´eveloppeur peut cr´eer ce qu’il souhaite dans son application, il peut utiliser un package existant, le modifier et/ou le d´eriver.
7.3. H´eritage en≪double cascade ≫ 145 7.3.2 Double cascade pour les fichiers
Pour profiter des fonctionnalit´es du moteur du framework et de l’application, les r´epertoires du framework et de l’application doivent avoir la mˆeme structure. Dans ce cas, lorsque le syst`eme a besoin d’un fichier donn´e pour un package, il commence par regarder si ce fichier existe dans les r´epertoires de l’application. Si c’est le cas alors il est utilis´e, sinon le syst`eme prendra le fichier pr´esent dans le cœur de Sydonie.
Ce m´ecanisme permet de red´efinir compl`etement un template donn´e. Par exemple, si le fichier de template edit.tpl.php de la classe Article est pr´esent dans l’application, alors ce sera lui qui sera utilis´e, et non le templateedit.tpl.php pr´esent dans le moteur de Sydonie.
De la mˆeme fa¸con, une classe donn´ee pourra ˆetre red´efinie enti`erement. Il suffit pour cela que le fichier d´efinissant la classe soit pr´esent dans l’application. Ce m´ecanisme s’ajoute aux possibilit´es d’h´eritage des classes pr´esent´es `a la section pr´ec´edente.
7.3.3 Application aux configurations
Le m´ecanisme de la double cascade permet de modifier les configurations d’un package. Cela inclut les configurations du mod`ele de document, des templates, des contrˆoles de formulaire, des labels et des actions. La double cascade donne la possibilit´e d’ajouter des informations de configuration mais aussi de modifier la configuration par d´efaut.
Prenons par exemple un type de document Article pour lequel on souhaite modifier le mod`ele de donn´ees, c’est-`a-dire pour lequel le d´eveloppeur veut red´efinir les attributs. Rappelons que le package Article d´erive des packages SydonieDocument et SydonieEntity, comme illustr´e figure7.6.
Le moteur de Sydonie et l’application ´etant d´ecoupl´es, chacun des packages parents de Articleposs`ede une configuration par d´efaut dans Sydonie et ´eventuellement une configuration sp´ecifique dans l’application. Pour connaˆıtre la configuration d’un document de type Article pour l’application, Sydonie va alors reconstruire la liste des attributs d’un objet Article. Pour cela, on remonte la cascade de d´erivation des packages en prenant `a chaque fois en compte les configurations de l’application avant celles sp´ecifi´ees dans Sydonie. Le fonctionnement est illustr´e par la figure7.6.
Lors de l’utilisation d’un document de type Article par l’application, Sydonie va reconstruire la liste des attributs en commen¸cant par les attributs d´efinis dans la configuration de l’application pour le packageArticle(no1 sur la figure). Puis le framework prendra les attributs d´efinis par d´efaut dans Sydonie pour le packageArticle(no2 sur la figure). Sydonie continue en remontant au packageparent o`u le mˆeme processus se reproduit (nos 3 et 4 sur la figure), et ainsi de suite jusqu’`a la ≪ classe m`ere≫ de plus haut niveau.
Ce m´ecanisme permet de d´efinir des attributs que l’on retrouvera pour tout un ensemble de
Figure 7.6 –H´eritage en cascade pour la configuration d’un type de document
packages d´eriv´es, mais aussi de modifier la nature d’un attribut au niveau de l’application.
Ce m´ecanisme est utilis´e pour les affichages : templates, labels, formulaires. Pour chacun d’entre eux, la double cascade est mise en œuvre.
Dans le cadre de la configuration des templates, ce processus est combin´e au m´ecanisme utilis´e pour les fichiers. Par exemple, si le fichier de template view.tpl.php doit ˆetre utilis´e pour le packageArticle, alors le syst`eme va d’abord regarder si ce fichier existe dans le package Article au sein de l’application. Si le fichier n’existe pas, le syst`eme cherche dans le cœur du framework. Tant que le fichier n’est pas trouv´e, le syst`eme remonte ensuite la liste des packages parents tout en regardant `a chaque fois dans l’application en premier. Le d´eveloppeur b´en´eficie donc des templates d´efinis par d´efaut dans Sydonie et peut, l`a encore de fa¸con simple, d´efinir ses propres templates sur les objets de l’application.
Le processus est similaire pour la d´efinition des labels, et la configuration des formulaires.
7.3.4 Conclusion
Nous avons pr´esent´e dans cette section et la pr´ec´edente les solutions qui r´epondent `a certaines attentes que nous avions formul´ees au chapitre4 et `a la section7.1.
Le d´eveloppeur d’applications web a toute libert´e pour d´efinir le mod`ele de son application.
Les m´ecanismes propos´es par le framework lui permettent de b´en´eficier d’une flexibilit´e de d´eveloppement. Il peut en effet cr´eer les packages n´ecessaires pour les besoins de son application.
Il peut aussi adapter un package existant en modifiant son mod`ele de donn´ees, ses actions, ses vues, ses labels et ses interactions de saisie.
Cette architecture a ´et´e appr´eci´ee des d´eveloppeurs. Ils ont alors pu se concentrer sur les sp´ecificit´es de l’application `a d´evelopper.