Commentaires à "yet another form/binding programming model"
(post du 10 modifié le 11) Laurent Caillette propose un cahier des charges et une solution de "GUI binding" sur son blog et je voulais le commenter... il est un peu temps mais bon !
1) Static binding.
En regardant les travaux Swing/Swinglabs sur ces sujets, on se dit que Static Binding est un super cahier des charges, mais il y a fort à parier qu'il ne soit pas repris par ces (futures) solutions "mainstream" précitées. Un autre cahier des charges moins bon mais acceptable (ah, compromis ? Compromission ?) serait : binding d'attributs "vérifiable", et idéalement compatible remaniement (refactoring).
De ce point de vue, binding XML à la Spring / SpringIDE, qui combine binding en XML spécialisé à un vérifieur, un éditeur autocomplétant XML intégré dans l'outil de développement, et compatible en partie avec le remaniement, est "acceptable". Mais je dis bien Spring AVEC Spring IDE. Quand tu fais disparaitre un attribut impliqué dans un binding, une "erreur" Spring surgit dynamiquement à côté des autres erreurs et avertissements de compilation traditionnelle dans la view "Problems".
De même, si Swinglabs conserve son binding basé EL (expression language), il sera urgent de rajouter dans les IDEs un plugin qui fouille le code et vérifie en temps réel les expressions, sans quoi la solution restera condamnée aux petits développements, type lecteur MP3 de démonstration.
1.1) Template model
J'aime bien cette idée de ne plus "mentir" dans le code; on ne binde plus un attribut de pseudo-bean mais un attribut de "template model", un objet dont on comprend son rôle. Pattern à suggérer à JGoodies Binding, bien pitoyable avec ses constantes de "nom de d'attribut".
Tiens, j'ai observé sur un projet une approche pragmatique intéressante dans un framework Gui : passer par des constantes de nom d'attribut mais qui sont généréés dans le process de build (en fait les "value objects" sont générés entièrement). C'est simple et répond quasiment au cahier des charges light ci dessus. Bon, le remaniement est sportif..
2) Validation côté serveur, côté client
On voit bien intervennir cette api de validation dans une couche de services "applicatifs", spécialisés pour répondre aux besoins des interactions écrans, qui apellent une couche "métier" qui gère ses erreurs "localement", dans leurs "petits" contextes. Avec cette observation : on n'insiste pas assez sur cette toute relative valeur apportée par cette couche qui "orchestre" le métier; elle peut être très maigre, qu'elle le reste surtout; et elle pourrait rester sur le client parfois... Qu'elle y reste aussi alors ! On n'a pas forcément à l'estampiller "server-side", c'est la (re)lecture d'un chapitre du PEEA de Fowler qui m'a interpellé là dessus. On en reparle au prochain post.
3) un petit manque, une fonctionnalité facilitant le maître-détail et consorts.
JGoodies parle de "bean channel" entre modèle bindé à la liste et modèle bindé au détail pour modifier automatiquement le bean du détail en fonction de la sélection (je vais publier une note à ce sujet dans la semaine).
Swinglabs Databinding le fournissait (refactoring en cours, ça peut changer !!) via le mot clef "selected" à utiliser dans les expressions EL de binding du détail qui faisait référence au maître (le refactoring en cours m'empêche un peu de tester...).
Je trouve qu'il y a là une bonne idée à creuser, et si j'étais toi, je le rajouterai.. Mais je te laisse être toi, héhé !
J'ai failli oublié de conclure; en conclusion mon commentaire est : ce cahier des charges et ces éléments de solution me comblent de joie ! A quand l'implem oss ? ;-)
1) Static binding.
En regardant les travaux Swing/Swinglabs sur ces sujets, on se dit que Static Binding est un super cahier des charges, mais il y a fort à parier qu'il ne soit pas repris par ces (futures) solutions "mainstream" précitées. Un autre cahier des charges moins bon mais acceptable (ah, compromis ? Compromission ?) serait : binding d'attributs "vérifiable", et idéalement compatible remaniement (refactoring).
De ce point de vue, binding XML à la Spring / SpringIDE, qui combine binding en XML spécialisé à un vérifieur, un éditeur autocomplétant XML intégré dans l'outil de développement, et compatible en partie avec le remaniement, est "acceptable". Mais je dis bien Spring AVEC Spring IDE. Quand tu fais disparaitre un attribut impliqué dans un binding, une "erreur" Spring surgit dynamiquement à côté des autres erreurs et avertissements de compilation traditionnelle dans la view "Problems".
De même, si Swinglabs conserve son binding basé EL (expression language), il sera urgent de rajouter dans les IDEs un plugin qui fouille le code et vérifie en temps réel les expressions, sans quoi la solution restera condamnée aux petits développements, type lecteur MP3 de démonstration.
1.1) Template model
J'aime bien cette idée de ne plus "mentir" dans le code; on ne binde plus un attribut de pseudo-bean mais un attribut de "template model", un objet dont on comprend son rôle. Pattern à suggérer à JGoodies Binding, bien pitoyable avec ses constantes de "nom de d'attribut".
Tiens, j'ai observé sur un projet une approche pragmatique intéressante dans un framework Gui : passer par des constantes de nom d'attribut mais qui sont généréés dans le process de build (en fait les "value objects" sont générés entièrement). C'est simple et répond quasiment au cahier des charges light ci dessus. Bon, le remaniement est sportif..
2) Validation côté serveur, côté client
On voit bien intervennir cette api de validation dans une couche de services "applicatifs", spécialisés pour répondre aux besoins des interactions écrans, qui apellent une couche "métier" qui gère ses erreurs "localement", dans leurs "petits" contextes. Avec cette observation : on n'insiste pas assez sur cette toute relative valeur apportée par cette couche qui "orchestre" le métier; elle peut être très maigre, qu'elle le reste surtout; et elle pourrait rester sur le client parfois... Qu'elle y reste aussi alors ! On n'a pas forcément à l'estampiller "server-side", c'est la (re)lecture d'un chapitre du PEEA de Fowler qui m'a interpellé là dessus. On en reparle au prochain post.
3) un petit manque, une fonctionnalité facilitant le maître-détail et consorts.
JGoodies parle de "bean channel" entre modèle bindé à la liste et modèle bindé au détail pour modifier automatiquement le bean du détail en fonction de la sélection (je vais publier une note à ce sujet dans la semaine).
Swinglabs Databinding le fournissait (refactoring en cours, ça peut changer !!) via le mot clef "selected" à utiliser dans les expressions EL de binding du détail qui faisait référence au maître (le refactoring en cours m'empêche un peu de tester...).
Je trouve qu'il y a là une bonne idée à creuser, et si j'étais toi, je le rajouterai.. Mais je te laisse être toi, héhé !
J'ai failli oublié de conclure; en conclusion mon commentaire est : ce cahier des charges et ces éléments de solution me comblent de joie ! A quand l'implem oss ? ;-)
Commentaires