Ellipse Tutorial Cycle de vie d'une page Ellipse et de ses composants

ATTENTION : Tutorial en cours d'écriture ! N'hésitez pas à nous signaler toute erreur ou suggestion.

Accès rapide :
   Les différentes étapes du cycle de vie

Ellipse mérite son titre de "framework" : il ne s'agit pas d'une simple librairie de développement d'applications Web, mais bien d'un système de développement d'applications Web imposant un cadre de programmation fort. Parmi les différents points imposés par ce framework, citons notamment le cycle de vie d'une page web. Ce cycle de vie impose l'invocation de méthodes particulières à des moments forts du cycle de traitement de la page Web. Le diagramme ci-dessous tente de synthétiser ce cycle de vie.

Afin de mieux comprendre les choses, nous allons maintenant reprendre un à un ces différents points du cycle de vie d'une page Ellipse.

1. Le cycle de vie de la page Ellipse commence par la construction de l'objet de page Web (dérivant de la classe corelib.services.web.webapplications.WebPage). Il est non conseillé d'utiliser le constructeur : à ce stade, l'objet n'est pas encore lié au fichier de définition de la page Web (extension .wp).
 
2. En seconde étape, le framework Ellipse cherche à gérer l'inclusion de fichiers. N'oubliez pas qu'une page Web Ellipse est forcément définie via un fichier XML. Il en va de même pour les différents fichiers inclus (via la syntaxe <include file="partOfPage.wp" />). L'inclusion est en réalité prise en charge en fusionnant les différents DOM (Document Object Model), pour n'avoir au final qu'un unique DOM représentant la page Web Ellipse complète. La fusion est obtenue en clonant simplement les tags XML, à l'identique, dans la page principale.
 
3. A ce stade le framework Ellipse cherche, pour chaque noeud du DOM associé à un composant Web, à instancier ces différents composants. N'oubliez pas que le namespace XML de chaque tag considéré est en fait associé à un package Java. N'oubliez pas non plus qu'il est aussi possible de faire en sorte qu'un nom de tag coïncide exactement à un nom de classe pleinement qualifié (ex: <corelib.services.web.components.Button />). Le framework Ellipse cherche aussi à injecter les attributs des tags de composants WEB dans les attributs de vos instances de composants Web en se basant sur le modèle JavaBeans.
 
4. Certains attributs de votre classe de page Web peuvent être associés aux deux annotations Ellipse corelib.services.web.annotations.Session et corelib.services.web.annotations.Session. Si tel est le cas, le framework Ellipse liera ces instances aux données associées (stockées respectivement en session ou dans l'application). Si les données n'existent pas à ce moment, le framework cherchera à les instancier (via le moteur de réflexion Java : il est donc obligatoire que les classes de ces données exposent un constructeur à zéro paramètre).
 
5. Pour tous les composants Web implémentant l'interface corelib.services.web.webapplications.DataRepeater (les répétiteurs de composants Web), on cherche à cloner les composants Web qu'ils contiennent. De manière standard, les répétiteurs de composants sont liés à des données en session ou stockées dans l'application. Pour tous les composants dupliqués, les identifiants des composants Web (propriété id) sont modifiés de manière à garantir l'unicité de chacun d'eux (l'indice de répétition leur est adjoint).
 
6. L'étape d'initialisation est alors déclenchée : elle est découpée en deux parties. Vous serez informé de cet état via une approche événementielle qui s'échelonne sur les deux étapes mentionnées ci-dessous (points 7 et 8).
 
7. La méthode component_init est invoquée sur chacun des composants Web. Attention : à ce stade là vous n'avez pas encore accès au données liées (via le Data Binding), ni aux données soumises par l'intermédiaire d'un formulaire (sauf, bien entendu, par l'intermédiaire de l'objet request - javax.servlet.http.HttpServletRequest).
 
8. La méthode page_init est invoquée sur votre page Web. Attention : à ce stade là vous n'avez pas encore accès au données liées (via le Data Binding), ni aux données soumises par l'intermédiaire d'un formulaire (sauf bien entendu par l'intermédiaire de l'objet request - javax.servlet.http.HttpServletRequest).
 
9. Le DataBinding (étape 1/3) débute en initialisant chaque composant Web avec les données des objets du modèle qui leurs sont liés.
 
10. Toutes les données soumises via un formulaire (en cas de soumission en POST) sont récupérées dans l'objet de requête et stockées dans les composants Web associés.
 
11. Le DataBinding (étape 2/3) se poursuit en recopiant les données (éventuellement modifiées par l'étape précédente) des composants objets vers les instances JavaBeans du modèle. Il vous sera ainsi possible lors de la gestion des événements de travailler, avec une approche purement objet, sur les objets du modèle (et non sur ceux de la vue - architecture MVC).
 
12. Les événements indiquant la fin du chargement de données de la page commencent à être invoqués : cela se poursuit durant les étapes 13 et 14. Notez que, contrairement à l'événement d'initialisation, vous avez accès, à partir de maintenant, à toutes les données mises en jeu par la page Web.
 
13. La méthode component_load est invoquée sur chacun des composants Web.
 
14. La méthode page_load est ensuite invoquée sur la page. Conventionnellement, c'est dans cette méthode que vous codez l'enregistrement des écouteurs (des listeners) sur les composants Web de la page (modèle événementiel proposé par le framework).
 
15. La gestion des événements sur les composants Web de votre page se poursuit. Les appels vont être lancés par blocs en respectant les cinq niveaux de priorités proposés par le framework (WebComponentEventLevel.FIRST, BEFORE, DEFAULT, AFTER et LAST).
 
16. Le DataBinding (étape 3/3) se termine. Les gestionnaires d'événements ont probablement modifié les données du modèle. Il faut donc transférer, une nouvelle fois, l'état des beans du modèle vers les composants Web, afin de préparer la phase de génération du rendu HTML.
 
17. La génération du rendu HTML débute maintenant : le DOM XML a peut-être été modifié par vos soins et les composants Web reflétant le nouvel état résultant des actions de l'utilisateur, on peut donc maintenant exploiter le tout pour produire la page HTML à retourner au client. Cette étape de génération de la page HTML se poursuit jusqu'au point 25.
 
18. La méthode page_preRender est invoquée sur la page Web considérée. Si quelques derniers ajustements sont nécessaires il vous est encore possible de réagir.
 
19. Ensuite, la méthode page_render est invoquée. Elle à pour responsabilité de cascader la demande de génération de flux HTML sur le tag racine du DOM et son composant Web associé (normalement le composant <web:Html>).
 
20. La méthode component_preRender est invoquée sur un composant pour l'informer qu'il est sur le point d'être sollicité pour prendre en charge son rendu visuel.
 
21. La méthode component_renderBegin doit générer le code HTML associé au tag ouvrant du composant Web considéré.
 
22. La méthode component_renderChildren doit générer le code HTML associé au contenu des sous-composants Web considérés. Il n'est pas forcément nécessaire de recoder cette méthode. Son implémentation au sein de la classe VisualComponent suffira dans la majorité des cas. Dans le cas ou le composant contient des sous-composants Web, l'implémentation par défaut repasse la main aux méthodes component_preRender, component_renderBegin, component_renderChildren, component_renderEnd et component_postRender, et cela pour tous les sous-composants.
 
23. La méthode component_renderEnd doit générer le code HTML associé au tag fermant du composant Web considéré.
 
24. La méthode component_postRender est invoquée pour signaler au composant Web considéré, que son travail de génération du flux HTML est terminé.
 
25. La méthode page_postRender est invoquée pour indiquer que la génération du flux HTML associée à la page Web est terminée.
 
26. L'objet de page Web est relâché par le framework. Il est maintenant possible que le GC (Garbage Collector) collecte cet objet (et ceux qui lui sont associés) : la méthode finalize pourra donc être utilisée.
 

ATTENTION : Ellipse Framework vous est proposé en version beta (d'évaluation) afin de vous permettre d'évaluer ce framework. Infini Software se dégage de toutes responsabilités relatives à l'utilisation de ce framework. De plus, Infini Software ne pourra nullement être tenu responsable de l'utilisation des informations présentes dans ces tutoriaux. Dominique LIARD - © 2007..2010 SARL Infini Software - Tous droits réservés Les autres marques et les noms de produits cités dans ces documents sont la propriété de leurs détenteurs respectifs.