First note in english... As our videos presented are in english, so does the comment :)
If you don't know (or just feel ) what's Web 2.0 , take a look at these videos... Web 2.0 is a dramatic improvement of the web, that's why I want to contribute to its developpement with Archetype, which is a way to help to separate website structures, website looks & feels, and website behaviours. For example the Grease Monkey Firefox extension is a way to web 2.5: web sites then behave as YOU expect ;)
The machine is us/ing us !
samedi 28 avril 2007
mercredi 25 avril 2007
Web 2 et les frameworks front serveur
Je parlerai ici du monde Java car c'est celui que je pratique, mais la reflexion doit pouvoir dépasser le langage serveur.
D'où est-ce qu'on vient ?
Archetype s'oppose à l'utilisation pauvre de l'Ajax pour seulement ajouter une Widget ou faire un reload dynamique d'une div. L'objectif est ni plus ni moins le développement en JavaScript. Ce sera encore longtemps le seul et unique moyen de créer une interface dynamique pour le Web.
Je vais enchaîner les évidences en précisant que cela nous amène à transposer notre code front depuis le framework front serveur vers le JavaScript. Plus on dynamise une page, plus il faut savoir la recomposer en JavaScript et plus la composition initiale côté serveur perds son intérêt.
Le coup de grâce arrive avec DWR. La possibilité de transférer vraiment simplement entre le JavaScript et le serveur des données construites fait que toute la construction HTML est aussi simple à faire en JavaScript qu'au niveau du serveur.
L'évidence qui suit paraît extrême mais ne l'est pas tant que ça finalement : le framework front serveur ne sert plus. Il y a bien des tentatives, surtout avec JSF, pour fondre le front serveur et le front client mais on remarque vite que cela ne donne que des widgets... Ce n'est pas adapté ! Essayez de coder Netvibes en JSF qu'on rigole ;)
Le Web 2.0, c'est le développement d'un client lourd avec une gestion événementielle très poussée et une dynamisation qui ne fonctionne pas sur le modèle des "pages web". Donc j'en remet une couche pour être sûr qu'on a bien compris : le modèle struts ou jsf des "vues" ou "pages" ou même "faces" n'est plus adapté.
Où est-ce qu'on va ?
Déjà, il y a Prototype pour transformer le JavaScript en un langage pratique ;). Ensuite il faut Archetype pour pouvoir utiliser Prototype facilement dans une application d'un minimum d'ampleur.
"Mais dans Struts ou JSF, on avait une belle structure qui permettait de coder efficacement avec une organisation stricte, le JavaScript c'est le bordel !". Ce à quoi je répond Oui ! Mais la réponse n'est pas de rester sur Struts et de faire du vieux Web, la réponse doit être : "Organisons le JavaScript" !
J'identifie deux principaux besoins :
Au final, on se retrouve avec une application embarquée chez le client qui demande aux serveurs deux choses distinctes : des templates ou des données construites. L'application embarquée traite les deux et les propose de façon dynamique à l'utilisateur.
Il y a beaucoup de travail en perspective et des problématiques à gérer. Une première problématique identifiée sera celle qui tient à coeur à celui qui a initié ce projet : l'accessibilité.
Une question reste ouverte, toutes ces idées ont-elles leur place dans Archetype ou doivent-elles seulement utiliser Archetype ? à suivre...
Edit : J'assume le fait que la réflexion n'est pas encore aboutie, d'ailleurs, je pousse un peu ma réflexion avec les deux idées suivantes :
D'où est-ce qu'on vient ?
Archetype s'oppose à l'utilisation pauvre de l'Ajax pour seulement ajouter une Widget ou faire un reload dynamique d'une div. L'objectif est ni plus ni moins le développement en JavaScript. Ce sera encore longtemps le seul et unique moyen de créer une interface dynamique pour le Web.
Je vais enchaîner les évidences en précisant que cela nous amène à transposer notre code front depuis le framework front serveur vers le JavaScript. Plus on dynamise une page, plus il faut savoir la recomposer en JavaScript et plus la composition initiale côté serveur perds son intérêt.
Le coup de grâce arrive avec DWR. La possibilité de transférer vraiment simplement entre le JavaScript et le serveur des données construites fait que toute la construction HTML est aussi simple à faire en JavaScript qu'au niveau du serveur.
L'évidence qui suit paraît extrême mais ne l'est pas tant que ça finalement : le framework front serveur ne sert plus. Il y a bien des tentatives, surtout avec JSF, pour fondre le front serveur et le front client mais on remarque vite que cela ne donne que des widgets... Ce n'est pas adapté ! Essayez de coder Netvibes en JSF qu'on rigole ;)
Le Web 2.0, c'est le développement d'un client lourd avec une gestion événementielle très poussée et une dynamisation qui ne fonctionne pas sur le modèle des "pages web". Donc j'en remet une couche pour être sûr qu'on a bien compris : le modèle struts ou jsf des "vues" ou "pages" ou même "faces" n'est plus adapté.
Où est-ce qu'on va ?
Déjà, il y a Prototype pour transformer le JavaScript en un langage pratique ;). Ensuite il faut Archetype pour pouvoir utiliser Prototype facilement dans une application d'un minimum d'ampleur.
"Mais dans Struts ou JSF, on avait une belle structure qui permettait de coder efficacement avec une organisation stricte, le JavaScript c'est le bordel !". Ce à quoi je répond Oui ! Mais la réponse n'est pas de rester sur Struts et de faire du vieux Web, la réponse doit être : "Organisons le JavaScript" !
J'identifie deux principaux besoins :
- Une structure MVC, mais une structure compatible avec la programmation événementielle.
- Un langage de templating HTML, il ne faut pas avoir à coder le HTML dans le code JS.
Au final, on se retrouve avec une application embarquée chez le client qui demande aux serveurs deux choses distinctes : des templates ou des données construites. L'application embarquée traite les deux et les propose de façon dynamique à l'utilisateur.
Il y a beaucoup de travail en perspective et des problématiques à gérer. Une première problématique identifiée sera celle qui tient à coeur à celui qui a initié ce projet : l'accessibilité.
Une question reste ouverte, toutes ces idées ont-elles leur place dans Archetype ou doivent-elles seulement utiliser Archetype ? à suivre...
Edit : J'assume le fait que la réflexion n'est pas encore aboutie, d'ailleurs, je pousse un peu ma réflexion avec les deux idées suivantes :
- Je détecte une très bonne nouvelle dans le fonctionnement : chaque client édite sa propre page, le serveur n'a que du statique à livrer en dehors des accès métiers réels. Conclusion : les exploitants vont être contents ;).
- Moteur de template, moteur de template... Oui mais pas Java. En effet, tous les principes basés sur les jsp tentent des solutions "xml-isantes" que j'ai toujours trouveés incompatibles pour les contrôles genre if ou for, conclusion : les solutions de type Smarty me paraissent bien plus sympathiques.
lundi 23 avril 2007
L'avancement
La version 0.1.0 n'est pas loin de sortir...
Mon problème actuel est de gérer l'insertion de javascript via
Le gros problème, c'est que le javacript, c'est mono threadé, sans l'être vraiment. Quand j'ajoute une balise script avec la source vers le fichier js, celui-ci se charge en fond. Si je fais une boucle d'attente pour verifier qu'une variable vient de dire "ok, c'est chargé", je me retrouve en fait dans une boucle infinie.
Dans le bootstrap, j'utilise des setTimeout (qui, eux, ne sont pas dans le même thread) mais ceux-ci impose de pouvoir appeler une nouvelle fonction lorsque la variable est disponible.... Ce que je ne souhaite pas imposer à l'utilisateur ...
J'ai donc essayé la requête XmlHttpRequest synchrone (qui marche plus ou moin bien lors du chargement de la page... mais surtout il semblerait, qu'apres le chargement du script, de retour dans mon code d'initialisation, les objets que je viens de charger ne sont pas disponibles dans mon thread ! :'( Pour autant c'est peut-être un problème local au chargement de la page car le chargement d'une page est ce qu'il y a de plus complexe à comprendre en javascript, je crois :D
Mon premier Archetype.require est utilisé par le Logger qui utilise la configuration pour savoir quel module de logger il doit prendre, et en déduire quel type d'objet sera le singleton Logger (je vous rassure, ils ont tous la même interface abstraite!)
Bref, j'ai pas mal de tests à faire et je vais devoir enquêter plus loin sur comment fait le require de dojo (qui a, a priori, le même but).
Edit: Après enquête , dojo charge le javascript via une XmlHttpRequest Synchrone, mais au lieu de mettre le résultat de la requête dans une balise script, le code chargé est directement interprêté!
A tester, donc :)
Mon problème actuel est de gérer l'insertion de javascript via
Archetype.require(module)En effet, pour que l'application ne dépende pas trop d'Archetype (j'aimerai ne pas emprisonner le développeur dans le framework ;o) ) il faut que ce require soit synchrone, c'est à dire qu'il charge le module, et que le programme attende que le module soit chargé dans le navigateur pour pouvoir l'utiliser.
Le gros problème, c'est que le javacript, c'est mono threadé, sans l'être vraiment. Quand j'ajoute une balise script avec la source vers le fichier js, celui-ci se charge en fond. Si je fais une boucle d'attente pour verifier qu'une variable vient de dire "ok, c'est chargé", je me retrouve en fait dans une boucle infinie.
Dans le bootstrap, j'utilise des setTimeout (qui, eux, ne sont pas dans le même thread) mais ceux-ci impose de pouvoir appeler une nouvelle fonction lorsque la variable est disponible.... Ce que je ne souhaite pas imposer à l'utilisateur ...
J'ai donc essayé la requête XmlHttpRequest synchrone (qui marche plus ou moin bien lors du chargement de la page... mais surtout il semblerait, qu'apres le chargement du script, de retour dans mon code d'initialisation, les objets que je viens de charger ne sont pas disponibles dans mon thread ! :'( Pour autant c'est peut-être un problème local au chargement de la page car le chargement d'une page est ce qu'il y a de plus complexe à comprendre en javascript, je crois :D
Mon premier Archetype.require est utilisé par le Logger qui utilise la configuration pour savoir quel module de logger il doit prendre, et en déduire quel type d'objet sera le singleton Logger (je vous rassure, ils ont tous la même interface abstraite!)
Bref, j'ai pas mal de tests à faire et je vais devoir enquêter plus loin sur comment fait le require de dojo (qui a, a priori, le même but).
Edit: Après enquête , dojo charge le javascript via une XmlHttpRequest Synchrone, mais au lieu de mettre le résultat de la requête dans une balise script, le code chargé est directement interprêté!
A tester, donc :)
Inscription à :
Messages (Atom)