Mise en œuvre de composants web via le framework Ellipse

[Ellipse Team]

L'objectif de ce nouveau tutoriel est de vous montrer comment créer des composants web réutilisables via le framework Ellipse. Deux types de composants web peuvent être envisagés : un composant web définit dans une simple classe Java, ou bien un composant web à base d'un modèle XML (TemplatedComponent) afin d'y stocker la mise en page pour le rendu HTML. Bien entendu, nous allons utiliser le plugin Ellipse afin de nous simplifier la construction de ces éléments. Ce tutoriel est accessible à partir de l'adresse suivante :
http://ellipse.developpez.com/tutori...s-web-ellipse/

Si vous avez des commentaires ou des questions, n'hésitez pas à compléter cette discussion.

L'équipe Ellipse

[mvvvv]

... ça fait rêver votre framework

[bugsan]

Le but de ce framework est de vous garantir une "haute productivité"

Sans vouloir être un peu trop médisant, faudrait penser à retomber sur terre et s'informer des solutions existantes (spring-mvc, jsf, play, wicket ...).

[Ellipse Team]

Bonjour.

En premier lieu, je vous remercie du temps consacré à la lecture du tutoriel et de ce message.

Pour en revenir au sujet de la discussion, je suis tout à fait d'accord avec le fait qu'il existe d'autres technologies : je les connais bien (pour certaines) pour les avoir utilisées sur plusieurs développements. Mais du coup, comparons quelques points sur la définition de composants avec la solution proposées.

JSF : que pensez-vous de l'obligation de définir les fichiers TLD alors que le modèle JavaBean suffirait à déduire les propriétés à exposer ? Est-ce que, de ce point de vue, la définition XML n'est pas redondante avec la définition de la classe ?

JSF toujours : comme JSF est basé sur JSP, pour définir un composant Web, il faut : 1_ définir la classe de tag pour le parsing de la JSP, et 2_ définir la classe de composant (pour le support du cycle de vie du composant). Du coup, les propriétés doivent souvent être dupliquées sur les deux classes. N'est-ce pas un peu anti-productif ?

JSF encore : que pensez vous d'être obliger de prendre en charge nous même la sauvegarde et la restitution de l'état du composant web ? Que pensez-vous du besoin d'enregistrement du composant dans le fichier faces-config.xml ? Encore une fois, est-ce très productif ?

SPRING MVC : de toute façon basé sur JSP, donc encore du XML en trop (TDL notamment, mais ...). Est-ce vraiment si productif ?

WICKET : de tous, mon préféré. Et là, les choses, effectivement, ne sont pas trop mal.

Pour en revenir à Ellipse : en fait, les principes fondateurs ne sortent pas de n'importe ou. En fait, je me suis beaucoup basé sur le modèle ASP .NET. J'ai donc tenté d'en faire une transposition pour Java. Et honnêtement, la simplicité de mise en œuvre de composant Web y est pas si mal que cela. Plus généralement, on peu développer une application Web avec un minimum de XML, ce qui n'est pas aussi simple avec JSF notamment (j'en pouvais plus de taper tous ces trucs inutiles). A titre indicatif, j'ai fait un test sur une application développée via JSF pour un client : après réécriture avec Ellipse, nombre de lignes (XML & Java) de code divisé par 3.

Dernier points : effectivement, dans la première partie du tuto, je présente le modèle de base. Il y a donc des out.println (c'est vrai). Mais le concept de TemplatedComponent, présenté en seconde partie, n'est-t-il pas un peu plus sympathique ?

Merci pour vos retours.
Cordialement,
L'équipe Ellipse

[bugsan]

Le XML, ce n'est pas sale. Et on ne peut pas vraiment y échapper lorsque l'on souhaite créer des composants qui générent des documents HTML, non ?

Pour la conception de composant web, je suggererais d'éliminer au maximum la génération de HTML par des "out.println("<script ...")".
L'utilisation de fichier template tel que ceux de JSP, JSF, velocity, wicket... sont bien plus adaptés.

[Ellipse Team]

Le XML, ce n'est pas sale. Et on ne peut pas vraiment y échapper lorsque l'on souhaite créer des composants qui générent des documents HTML, non ?

Je suis tout à fait d'accord avec ce point, du moins tant qu'il n'est pas utilisé à tord et à travers. D'ailleurs, notre framework utilise beaucoup le XML : définition des vues (des pages web), définition des template de composant (comme montré en section V du tutoriel associé à ce fil de messages), ...

Par contre, il y a t'il quelqu'un qui peut me donner un intérêt (autre que le fait que le modèle JSP/JSF en ont besoin) à la définition d'une TDL ou à l'enregistrement d'un composant JSF dans le faces-config.xml ? Si quelqu'un peut me justifier leur intérêt, je suis preneur. Par contre, s'il n'y a aucun intérêt, alors c'est une perte de temps pour le développeur (et donc baisse la productivité des équipes de développement). En espérant garder les pieds sur terre , c'est notamment sur ce point que nous estimons proposer une solution de plus haute productivité (au moins par rapport à JSP, JSF et SPRING MVC).

Pour la conception de composant web, je suggererais d'éliminer au maximum la génération de HTML par des "out.println("<script ...")".

Nous sommes toujours d'accord et comme montré en seconde partie du tutoriel, c'est bien entendu la solution que nous préconisons. Nous sommes tout à fait d'accord pour limiter au maximum l'utilisation des out.println. Alors, pourquoi en parlons nous : certaines personnes remettent en cause l'utilisation de template XML car cela est relativement consommateur en ressources utilisées par le serveur (CPU & mémoire ; et ce point est indiscutable). Si ces personnes le souhaitent, elles peuvent ne pas utiliser nos templated component. Nous cherchons à répondre à un maximum de besoins.

Mais oui, limiter les out.println nous semble aussi être une bonne chose.

Cordialement

PS : conscient du fait que le tutoriel ne met pas suffisamment l'accent sur la partie Templated Component (je m'incline), je viens de rajouter dans la section V les trois derniers exemples de code.

[bugsan]

Envoyé par Ellipse Team

Par contre, il y a t'il quelqu'un qui peut me donner un intérêt (autre que le fait que le modèle JSP/JSF en ont besoin) à la définition d'une TDL ou à l'enregistrement d'un composant JSF dans le faces-config.xml ? Si quelqu'un peut me justifier leur intérêt, je suis preneur. Par contre, s'il n'y a aucun intérêt, alors c'est une perte de temps pour le développeur (et donc baisse la productivité des équipes de développement). En espérant garder les pieds sur terre , c'est notamment sur ce point que nous estimons proposer une solution de plus haute productivité (au moins par rapport à JSP, JSF et SPRING MVC).

L'écriture d'un TLD est requise uniquement lorsque l'on souhaite produire un livrable rassemblant des composants graphiques, réutilisables. Par exemple, à l'échelle d'une entreprise, un ensemble de composants qui sont repris dans plusieurs appli. Idem pour le faces-config, qui est présent aussi dans toutes les bibliotheques de composants JSF (myfaces, richfaces, icefaces, machin-bidule-faces).
L'intérêt de ces fichiers, c'est la documentation embarquée des composants, qui va de pair avec l'auto-completion dans Eclipse.

Si ce sont des tags JSP au sein de l'appli web, pas besoin de TLD (Eclipse gère l'auto completion en inspectant la JSP).

Lorsqu'on utilise des framework comme GWT, ou autre DSL internes, la doc est dans la javadoc, et l'autocompletion est faite par l'éditeur java ce qui évite à écrire un plugin Eclipse.

Pas d'autocompletion = perte de productivité (on peut parler de perte quand le monde entier propose cette fonctionnalité).


Spring-MVC ne propose pas de technologie de vue...

Envoyé par Ellipse Team

certaines personnes remettent en cause l'utilisation de template XML car cela est relativement consommateur en ressources utilisées par le serveur (CPU & mémoire ; et ce point est indiscutable)

Je ne comprends pas cette remarque. Tous les moteurs de templates opèrent une compilation. Vers du bytecode dans le cas de JSP. Vers du javascript dans le cas de GWT. Vers un model sémantique (arbre) comme dans JSF.

Le template n'est pas parsé à chaque fois qu'on veut l'utiliser !!

[kisitomomotene]

Vous pouvez objectivement me dire pourquoi quelqu'un adopterait ce framework? vous semblez très focalisé sur JSF/TLD JSF/JSP pour justifier la raison d'être de votre framework, les choses ont déjà trop évolué de ce côté avec Facelet, Seam, CDI (jee6) , si bien que JSF/TLD JSF/JSP c'est de la préhistoire aujourd'hui.
Et je ne vois pas en quoi l'utilisation des out.println améliorerait une quelconque productivité. Et de façon évidente, c'est la meilleur façon de rendre sa vue non évolutive et non maintenable.

[Ellipse Team]

Bonjour.

vous semblez très focalisé sur JSF/TLD JSF/JSP pour justifier la raison d'être de votre framework, les choses ont déjà trop évolué de ce côté avec Facelet, Seam, CDI (jee6) , si bien que JSF/TLD JSF/JSP c'est de la préhistoire aujourd'hui.

Pour l'aspect préhistoire, je suis bien d'accord et c'est ce que j'ai essayé d'expliquer plus haut. Mais je dois mal m'exprimer : les aspects de complétion et de documentation (vital dans la mise en œuvre d'une librairie de composants réutilisables) peuvent être réalisés sur une seule et unique classe de composant. D’où encore la question : à quoi servent les TLDs et autres qui sont des technos archaïques.

Pour l'aspect facelet, c'est vrai c'est mieux, mais je rappelle que c'est ce que Oracle préconise par défaut le support JSF par dessus JSP :
Pour utiliser Facelet, il faut rajouter un librairie apache complémentaire. Du coup, il faut assembler plusieurs solutions différentes. Encore une fois est-ce super productif ? Pour mémoire, dans le cas de l'utilisation du couple JSF/Facelet doit-on toujours dupliquer la définition des propriétés exposées par le composants JSF dans le faces-config.xml (alors qu'on a JavaBeans) ?

Et je ne vois pas en quoi l'utilisation des out.println améliorerait une quelconque productivité.

On est d'accord : les out.println ne sont pas une finalité en soit ! Pourquoi personne ne veux parler de la proposition sur les templated component ? Pourquoi bloquer sur ces fameux out.println ? J'en ai parler dans le tuto juste pour présenter la couche de base. Mais oui, ce n'est pas la solution la plus productive et je ne crois jamais avoir dis cela.

Pour finir ce tutoriel ne parle que de la mise en œuvre de composants web via le framework Ellipse. Ce n'est qu'un point parmi beaucoup d'autres. De nombreux autres tutoriels sont proposés sur notre site et devraient passer au format Developpez.com prochainnement. Pour l'heure voici les deux autres tutoriels sur le sujet déjà migrés. Peut être sauront-ils plus vous convaincre.

http://ellipse.developpez.com/tutori...pse-framework/
http://ellipse.developpez.com/tutori...-page-ellipse/

Cordialement