En 2009, lors de la conférence Google I/O, la session Best Practices for GWT nous présentait les patterns MVP et Event Bus, et leur application en GWT. S'en est suivi une poignée d'implémentations opensource sur googlecode (ici, là ou là) pour mettre en pratique ces bons conseils.
Pour 2010, la roadmap GWT nous annonçait un MVP "officiel", d'où de nombreuses interrogations de la part de ces communautés et une grosse attente du côté du forum des utilisateurs. Vient alors la wave de "design collaboratif" de Ray Rayan, qui sème un sérieux trouble. On y parle de data-binding, d'une nouvelle mécanique client serveur, et pas tellement de MVP ... en tout cas pas dans les termes de 2009 !
Voici qu'arrive bikeshed et sa démo Expense. L'analyse du code de l'exemple montre une véritable usine à gaz dont on comprend mal les rouages, avec pléthore de classes techniques. On comprend rapidement que cette infrastructure doit in fine être générée par l'outillage. Tiens, justement, Google annonce son rapprochement avec Spring Roo sur ce sujet !
Et hier, poum, la nouvelle tombe : bikeshed est mis au placard et retiré du trunk - ce nom étrange était-il prémonitoire ? Il n'en reste que le mécanisme d'échange avec le serveur RequestFactory (basé sur JSON) permettant de faire le lien entre un backend JPA et des DTO utilisés dans l'IHM GWT, et la génération de squelette est déportée dans Spring Roo.
bikeshed était très - trop - ambitieux et complexe. Si un socle MVP fait bien sont apparition dans GWT 2.1 (com.google.gwt.app) il ne reprend pas le vocabulaire de la session Google I/O 2009 et manque cruellement de documentation, en étant de plus marqué "Expérimental". Je regrette que l'équipe GWT se soit embarquée sur un terrain aussi glissant, plutôt que d'inclure un développement externe qui a déjà fait ses preuves et porté par une communauté, comme ils l'ont fait au préalable avec l'incubateur. Les diverses approches MVP proposées en opensource ont fait leur preuves et ne vont même pas souffrir de la concurrence d'un framework mal documenté et expérimental, même intégré au SDK.
Je ne pense pas que cela empêche l'innovation : de très bonnes extensions comme gwt-fx ou gwt-dnd proposent des fonctionnalités qui étendent le scope de GWT vers plus d'interactivité. Flex comme Java/Fx proposent un mécanisme de data-binding pour lier le modèle à la vue en une ligne de code, ce que nous devons faire à grand coup de Handlers et d'événements sur l'Event-Bus en GWT. Des solutions de binding GWT existent pourtant de longue date en opensource : le support des ProperyChangeListeners JavaBean - élément clé du DataBinding - a été proposé dès GWT 1.4, mais le sujet reste non-prioritaire
Wait & See comme on dit ...
1 commentaires:
J'ai pas tout suivi, mais il me semblait que la plupart des api introduites dans bikeshed avaient été merged dans le trunk justement ?
Tout ce qui est cell/place/validation/requestFactory ?
Après, c'est sûr qu'on est très loin d'avoir un framework mvp qui donne un cadre solide. J'ai l'impression que les extensions alternatives font ça mieux pour l'instant.
La version finale de Gwt 2.1 est prévue pour le 19 octobre si elle suit toujours le calendrier de Roo, wait and see...
Enregistrer un commentaire