Version imprimable
Je prends régulièrement contact avec des membres du forum dont j'apprécie les interventions et pour lesquels j'imagine que ce projet pourrait leur faire écho.
Je propose de poster les extraits les plus significatifs sur ce fil.
J'espère ne pas trahir l'esprit des auteurs en sortant de leur contexte certains paragraphes.
Citation:
Un code doit être parlant.
Voici ma vision d'un code parlant (et non pas simplement auto-descriptif), il doit refléter une logique applicative. Chaque méthode public (c'est plus ou moins valable également pour les méthodes privées) définit un service et ce service est généralement décrit dans les services rendus par l'application. L'implémentation de la méthode se doit de suivre la logique de l'application sinon c'est difficile à maintenir/relire/débugger/etc.
Je distingue parlant et auto-descriptif car ce dernier signifie à mes yeux que seul le code est porteur de sens et implique qu'il faille toujours implémenter l'algorithme natif. Alors qu'on peut faire un code non auto-descriptif sans être brouillon et être bien commenter (pas nécessairement documenter) pour faire le lien avec la logique applicative/algorithme natif.
Citation:
La première page "Le postulat de départ" est exactement le genre de première page que j'aime avoir sur un framework : quoi, qui, comment, où, pourquoi et leurs contraires "pas quoi", "pas qui", "pas comment". Cela permet un d'être sûr que c'est le framework qu'il nous faut, comment il résout notre problématique et les problèmes qu'il nous résoudra pas. Je me souviens d'avoir fait une étude de comparatif de librairies de couverture de code et qu'une librairie ne permettait pas de "couvrir" les blocs "catch" et les blocs en général s'il y avait une exception. C'était documenté nulle part et c'est sur le forum que l'un des concepteurs m'a indiqué que c'était dans l'idée de leur librairie et qu'ils trouvaient ça tout à fait normale ...
Citation:
D’emblée, il est certain que le projet est intéressant et bien ciblé (application Desktop) ... et très ambitieux.
Il est d'ailleurs étonnant que le monde Java n'ai pas déjà un outil de ce type
qui permette de bâtir rapidement une application Desktop en quelques jours.
J'ai beaucoup développé en MSAccess que j'ai bien apprécié pour sa facilité
à construire une application complète en un rien de temps. Mais en Java, rien ...
NetBeans permet de faire de beaux écrans de saisie,
mais il faut que le développeur se débrouille pour dialoguer avec le SGBD.
Tout cela pour dire que vous êtes dans la bonne direction.
Il existe un vrai besoin de génération d'écrans connectés directement au SGBD.
En ce qui concerne le design du code, il faudrait que je l'examine en détail pour en parler.
Les quelques échantillons que vous publiez me semble clairs et utilisables.
Je suppose que votre légitime ambition est de voir votre travail utilisé par des développeurs.
Aussi, je vais faire un parallèle avec un autre projet Open Source : Jasper Report
qui est une bibliothèque permettant de générer toutes sortes d'états (papier, pdf, html, Excel, etc..)
avec des fonctionnalités extraordinaires à rendre Microsoft vert de jalousie !!!
Or ce super outil a bien failli sombrer dans un super oubli.
Le design des états est fait en XML et c'est un vrai défi de le coder.
Heureusement, ses concepteurs y ont ajouté un EDI très efficace : iReport
qui permet de dessiner l'état avec une facilité déconcertante (il est même utilisé par des non-informaticiens)
Pardon d'avoir été un peu long, mais ce qui donnerait toute sa force à votre projet
serait d'avoir un EDI capable de lire la structure de la base de données,
de présenter les champs en liste (avec leurs types numérique, texte, date ...)
et d'un coup de drag and drop sur l'écran, on pourrait composer l'IHM.
Bien entendu, le code est tout de même généré derrière.
C'est un projet énorme, mais cela ferait gagner des années aux développeurs.