Tags
CRUD, Grails, Java, ROO, RubyOnRails, Scaffolding, Spring, SpringOne Europe 2009
Vaguement mentionné à SpringOne Americas 2009 en fin d’année dernière, Spring ROO avait depuis été évoqué ici et là mais sans jamais se montrer vraiment, laissant ainsi ses observateurs dans l’expectative. Ce n’est d’ailleurs pour ma part que Lundi lors de la keynote d’introduction à SpringOne Europe 2009 de Rod Johnson que j’ai découvert Spring ROO. Cette fois-ci, Ben Alex, son auteur, nous a fait une démonstration live de ROO nous permettant de nous faire une idée plus précise de ce mystérieux projet. Depuis Lundi, quelques détails sur ROO ont été mentionnés et je vais essayer de vous donner quelques informations supplémentaires.
Spring ROO est un genre de Grails ou Ruby on Rails pour le langage Java. Tout comme avec Grails, avec ROO, on a le choix de ne pas choisir, l’architecture est imposée: en gros Hibernate, Spring IoC et Spring MVC. La convention est préférée à la configuration, tout en restant configurable. Tout comme avec RoR et Grails, une interface en ligne de commande permet de contrôler le framework et le scaffolding tient une place de premier ordre dans le framework.
Stephan Schmidt, l’un des développeurs de Spring ROO a publié sur son blog le déroulement pour créer une petite application, et ROO n’étant pas encore sorti, c’est la seule source pour trouver des examples.
Là où Spring ROO se distingue, c’est que le scaffolding peut se faire à la volée ! Pas besoin d’invoquer un générateur de code, les méthodes helpers, et d’accès aux données CRUD sont générées à la volée ! Par ailleurs, les entités peuvent soit être crées en ligne de commande avec le shell interactif soit tapé à la main. Dans les deux cas, ROO détecte les modifications de la même manière et scaffolde les méthodes helper et d’accès aux données. Sous Eclipse, un support particulier fourni par SpringSource Tool Suite (d’ailleurs annoncé comme gratuit à partir de maintenant !) permettra d’en bénéficier de manière transparente.
Une autre particularité de ROO réside dans le fait qu’il vient avec un shell interactif avec complétion contextuelle. La complétion se fait avec la touche tabulation. Il semble très agréable à utiliser. C’est un genre de shell “fluent”. De la même manière qu’une API fluente, tout est à la portée de la main, concis, naturel, la complétion est fonction du contexte.
Par exemple, voici l’idée:
- lorsque l’on ouvre le shell, la complétion propose uniquement de créer un projet ou de quitter
- après avoir crée un projet, la complétion propose de créer une entité
- après avoir crée une entité, la complétion propose des commandes d’ajout de propriétés à celle-ci.
C’est très simple mais diablement efficace, il suffit d’enchainer quelques lettres et la touche tabulation pour créer en quelques lignes quelques entités, les contrôleurs et les interfaces CRUD.
Enfin, bien que l’architecture proposée par défaut par Spring ROO soit pré-définie et que certains choix soient controversés comme le code d’accès aux données placé dans des méthodes statiques directement dans les entités, j’ai pu discuter avec Ben Alex qui m’a confié que ROO serait customizable. Il y aura une SPI permettant de venir plugger de nouveaux templates de génération de code. Cette SPI devrait montrer le bout de son nez pour la première milestone.
Spring ROO est encore en version alpha, et n’est pas encore disponible … ah en fait je m’aperçois alors même que je finis d’écrire ces lignes que Spring ROO est maintenant téléchargeable depuis la page du projet !
Guillaume said:
Oh,
J’ai eu un petit espoir en lisant ce post mais après avoir joué 5min avec les exemples, je n’en reviens toujours pas qu’on puisse appeler ce “framework” un ‘Java On Rails’ … C’est d’ailleurs plus en générateur d’application qu’un framework.
Pour moi Play! (http://www.playframework.org) est un vrai ‘Java on Rails’ …
Cédric Vidal said:
Bonjour Guillaume,
Je n’ai pas affirmé que ROO était un ‘Java on Rails’, je m’interroge simplement sur le fait que ROO puisse en être un.
Par ailleurs, même si avec RoR (Ruby on Rails) et Grails, grâce aux capacités de méta programmation de leurs langages respectifs Ruby et Groovy, la génération de code se fait au runtime, ça n’en n’est pas moins de la génération de code !
Quant à ROO, même s’il impose que les entités soient annotées avec des annotations @Roo* pour bénéficier du scaffolding des méthodes d’accès aux données CRUD, des getter/setter, toString et equals, … les annotations @Roo* ont une rétention de niveau source, elle ne sont pas nécessaires au runtime, le tissage se fait à la compilation, Roo n’est donc pas du tout un framework, c’est exclusivement un générateur de code !
Mais par dessus tout, ce qui m’intéresse plus que le fait de savoir si ROO peut être légitimement qualifié comme un “Java on Rails”, c’est de savoir si ROO constitue une réelle réponse made in Java face aux frameworks type Rails, que la génération de code se fasse au runtime ou au build-time.
Et puis, ROO vient tout juste de sortir et je suis sûr que Ben Alex, son auteur, écoutera d’une oreille avertie les remarques qui ne manquerons pas de fuser. Attendons d’avoir plus de recul sur cette nouvelle technologie avant de l’écarter trop rapidement.
Quant à Play!, je vois que tu es l’un des auteurs, je ne connaissais pas, je ne vais pas manquer d’y jeter un coup d’oeil pour me faire mon propre avis si tu le veux bien sur le fait que ce soit un ‘vrai’ Java on Rails 😉 Merci pour le tuyau.
Pingback: ProxiAD vous parle d’IT » Model Driven » MDSD Scaffolding #1 Le scaffolding appliqué au MDSD, explication par l’exemple