Le gain en productivité est indéniable, bien que l’on soit très orienté CRUD ce qui est le cas de ZenContact et ce que tu soulignes fort justement dans ta conclusion.

Comme tu le dis, l’approche vue de Wicket est différente, on part de pages xHTML faite par un designer, et on développe l’application, qui est elle en Java, en bindant les composants avec les parties dynamiques du site.

En tout cas, un critère important de choix aussi entre les deux technologies en entreprise sera le suivant : « jsp / groovy » ou « xHTML / Java » (Bien entendu il existe d’autres critères et d’autres technologies comme Flex et GWT) et pourquoi bientôt Spring Roo qui permet d’avoir du Grails mais en Java.

Pour les aspects CRUD, il est possible de mentionner Celerio qui permet de générer toute l’application à partir du schéma de la base de données, je vais leur demander de participer au concours avec leur outil qui hormis les aspects Drag&Drop et Label éditable doit permettre de générer une grande majorité de l’application.

Cependant, je n’ai pas vu mention du label éditable quand on clique dessus, mais le composant doit aussi exister en Groovy/Grails. Certes l’approche composants facilite ce genre de choses en Wicket. Mais cela me permet de poser la question sur la façon dont on intègre une librairie Javascript. Par exemple pour ajouter l’intégration de YAV, une librairie JS, il faut créer un Behavior (une classe Java) qu’on ajoute ensuite au formulaire et qui du coup peut être réutilisé sur tous les projets.

Un grand merci à nouveau pour ce comparatif, c’est le but de cette application en tout cas, et j’espère qu’il y aura d’autres tentatives avec d’autres technos !

@Benoit
J’espère aussi que tu te trompes, mais ce genre de situations arrivera certainement. Plus le cout d’entrée sur une techno est bas, plus le risque d’y placer des développeurs trop rapidement formés est grand…

C’est ce qui fait par exemple la force et la faiblesse du monde PHP. Et pour le coup, un framework tel que symfony est une aubaine pour cet univers : il demande de s’investir pour l’utiliser, mais est très structurant et force les bonnes pratiques.

Dans le genre « série d’articles autour de la réalisation d’une application » Grails, vous pouvez aussi lire les articles de Cyril Brouillard : http://blog.excilys.com/tag/series-grails-albums/ (série en cours de publication).

C’est étrange, il me semblait que prototype était une dépendance de Scriptaculous… (http://www.clever-age.com/veille/publications/developpement-specifique/fiches-produits/prototype-et-script.aculo.us.html)

En important scriptaculous, tu dois donc aussi logiquement avoir accès aux fonctions de prototype sans avoir à l’importer de façon explicite. Il y a peut être un conflit de version entre le prototype importé explicitement et celui importé en tant que dépendance de scriptaculous?

C’est marrant, je suis un programmeur Java et je me suis remis au PHP avec le framework symfony ces derniers jours et il y a un nombre de similitudes étranges entre les commandes Grails et les commandes Symfony. Je te rejoins totalement quand tu dis que le développement Java classique à du soucis à se faire…