Accès rapide : La genèse Les objectifs visés
Ce projet est né d'une synthèse des nombreux systèmes existants de mise en oeuvre d'applications WEB. Le constat fut sans appel : tous les systèmes étudiés présentaient des idées intéressantes, pour autant tous s'arrêtent sans aller au fond des choses. Il m'a donc paru intéressant de tenter de fournir un nouveau framework intégrant un certain nombre de concepts favorisant une productivité accrue (en terme de temps de développement) mais en laissant de coté les points négatifs de certaines solutions, et, en parallèle, en y injectant quelques nouvelles idées permettant d'aller encore plus loin.
A titre d'exemple, considérons le modèle de pages JSF (Java Server Faces, proposé par SUN Microsystems). Bien que très efficace, il présente quelques lourdeurs. A mon sens, le problème le plus bloquant sur ce système, réside dans le fait que JSF est une surcouche du modèle JSP. Or celui-ci est très réducteur si l'on considère la notion de composants WEB. Effectivement, en JSP, vous pouvez définir vos propres bibliothèques de tags (les fameuses taglibs) : or même si la page contient plusieurs instances d'un même tag, une seule et unique instance Java (classe javax.servlet.jsp.tagext.TagSupport) permettra de charger en mémoire les valeurs des attributs de ces tags. Il est donc compliqué d'envisager un modèle de programmation Web événementiel basé sur JSP, étant donné qu'une unique instance de classe de tag est recyclée. JSF Contourne le problème en rajoutant la notion de classe de composant. Cette classe sera utilisée pour produire autant d'instances que de tags présents dans la page web. Mais du coup, pour coder un composant JSF, il vous faut au minimum coder deux classes (la classe de tag et la classe de composant) et de plus, il vous faudra aussi éditer deux fichiers XML (le fichier .tld pour la définition de la librairie de tags JSF et le fichier de configuration du contrôleur JSF (WEB-INF/faces-config.xml). C'est très lourd, d'autant plus que Java propose le modèle JavaBeans !
Au contraire, le framework NWS vous permet de développer un composant Web en codant, à priori, une seule et unique classe. Il n'est, de plus, pas nécessaire de définir, via une syntaxe XML, la liste d'attributs supportés par le tag XML : le modèle JavaBeans suffit amplement ! Un attribut d'un tag de la page Web correspond à une propriété (méthodes get/set) de votre classe de composant Web.
Un autre exemple : JSF, ou ASP .NET (solution de Microsoft), permettent l'utilisation d'un composant serveur au sein d'une page Web, en utilisant un tag XML : celui-ci sera constitué de deux parties séparées par un caractère ":". Par exemple <h:outputText> ou encore <asp:TextBox>. Or pour définir le préfixe (asp, h, ou autre) il vous faut utiliser une déclarative de page (commançant par <%@). Or ne s'agit t'il pas d'un namespace XML ?
NWS propose, quand à lui, l'utilisation des notions de namespace et d'URI (recommandés, je vous le rappelle, par le W3C) pour introduire le package dans lequel la classe Java associée au tag XML, sera située. Il apparaît donc clairement que le framework NWS (utilisant le langage de programmation java) ne s'appuie nullement sur les pages JSP ou bien JSF. Voici un petit exemple.
01 <?xml version="1.0" encoding="ISO-8859-1" ?> 02 <web:Html xmlns:web="corelib.services.web.components" 03 codeBehind="corelib.services.web.samples.virtualcaddy.webpages.Login"> 04 <head> 05 <title>Logon screen</title> 06 <link rel="stylesheet" type="text/css" href="CssStyles.css" /> 07 </head> 08 <body> 09 <h1>Logon screen</h1> <br /> 10 11 <web:Form focus="txtLogin" method="post"> 12 <div align="center"> 13 Login : <web:TextBox id="txtLogin" value="toto" /> 14 <web:RequiredValidator componentToValidate="txtLogin" 15 errorMessage="Value is required" cssClass="Validator" /> 16 <br/> 17 18 . . . 19 </div> 20 </web:Form> 21 </body> 22 </web:Html>
Le framework NWS a été développé (et continuera à l'être) en se focalisant sur un objectif principal : garantir la productivité la plus forte possible (en terme de temps de développement) pour les équipes de développement. Pour ce faire, tout mécanisme induisant un surcoût en temps de développement sera évité, même si celui-ci aurait pu garantir des performances en temps d'exécution plus poussée. Le temps de réponse du framework pour construire une page HTML, ne sera en aucun cas la priorité qui orientera les concepts proposés par NWS. Néanmoins, toute notre attention sera portée sur la qualité du code produit pour implémenter les différents concepts proposés.
Dans cet état d'esprit, le framework pourra être amené à subir des changements d'implémentation. Les méthodes et des classes pourront donc être ammenées à être supprimées du framework. L'utilisation de la dépréciation ne sera pas forcément retenue, au profit de modifications pures et simples. L'objectif de ce choix étant d'éviter un enfermement progressif du framework, qui pourrait à terme le rendre obsolète. De ce point de vue, on peut aujourd'hui considérer que certaines parties du J2SE ou du J2EE sont inadaptées (ce à cause d'un souci de compatibilité avec les versions précédentes). Nous chercherons à faire en sorte que cela ne sera pas le cas pour le framework NWS.
Les javadocs proposées sur ce site ainsi que ce tutorial seront en permanence maintenus à jours afin de vous aider à tirer profit de toutes les nouveautés qui sont et qui seront progressivement apportées au framework.
Enfin, notez que la volonté de ce framework ne va pas se limiter à fournir des solutions coté serveurs. Une librairie Javascript relativement riche vous permettra d'envisager la production d'applications Web d'une grande richesse visuelle (menu dynamique, arborescences, onglets, ...). Néanmoins cette partie du framework arrivera dans un second temps.
Dominique LIARD - © 2007 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.