Grails est un
framework orienté web écrit en Java et
Groovy et placé sous licence Apache. Il s'inspire fortement du framework
Rails (Ruby on Rails) avec notamment la notion de convention (vs configuration) permettant de n'avoir que le minimum de configuration nécessaire, un vrai bonheur pour le développeur. Mais contrairement à Rails, Grails est complètement dans l'univers Java, le framework se repose ainsi sur des frameworks "stars" de Java comme Spring ou Hibernate lui donnant d'office une maturité évidente (sans parler du fait qu'il devient par la même occasion complètement "crédible" en entreprise).
La sortie de la version 1.0 risque de donner une nouvelle dimension au projet, et il suffit de regarder l'activité de la liste de diffusion pour réaliser à quel point ce framework a de beaux jours devant lui.
Le seul bémol concernerait la prise en charge des
IDE. Il existe des greffons pour Eclipse et NetBeans mais encore trop jeunes. Le seul greffon vraiment avancé à l'heure actuelle est celui pour IDEA IntelliJ (IDE excellent mais qui n'est malheureusement pas OpenSource).
Aller plus loin
# Hum...
Posté par rhizome . Évalué à 8.
Trop gros, passera pas.
[^] # Re: Hum...
Posté par 🚲 Tanguy Ortolo (site web personnel) . Évalué à 0.
[^] # Re: Hum...
Posté par Anonyme . Évalué à 6.
[^] # Re: Hum...
Posté par Stéphane Traumat (site web personnel) . Évalué à 6.
http://about.me/straumat
[^] # Re: Hum...
Posté par turman (site web personnel) . Évalué à 7.
Mais si vous avez d'autres frameworks web qui offrent autant de fonctionnalités que (G)rails tout en étant bien plus léger, n'hésitez surtout pas à nous en faire part ici..
[^] # Re: Hum...
Posté par Yann KLIS (site web personnel) . Évalué à 3.
Se veut un concurrent très sérieux de Rails, même si aujourd'hui, ça reste un peu plus brut de décoffrage (comme Rails il y a 3 ans en somme).
[^] # Re: Hum...
Posté par Encolpe DEGOUTE (site web personnel) . Évalué à 1.
>>> (sans parler du fait qu'il devient par la même occasion complètement "crédible" en entreprise)
# Pour les ide
Posté par Anonyme . Évalué à 1.
Sans compter un bug bloquant pour moi : Swing n'arrive pas a utiliser le presse papier lorsque synergys est en route, donc tous les copier coller entre les machines sont en vrac, plutôt pénible quand on utilise une machine pour le dev et l'autre pour les docs.
Aptana aussi n'est pas fini non plus, je me suis rabattu sur kdevelop, beaucoup moins intégré mais j'y trouve plus mon compte.
Il reste bien le plugin vim pour rails qui apparemment est excellent, mais ca reste pour les amateurs, dont malheureusement je ne fait pas partie.
# Merci!
Posté par Lol Zimmerli (site web personnel, Mastodon) . Évalué à 1.
La gelée de coings est une chose à ne pas avaler de travers.
[^] # Re: Merci!
Posté par turman (site web personnel) . Évalué à 8.
# Oui mais Grails c'est aussi Groovy...
Posté par rvalyi . Évalué à 5.
Grails est sans doute déjà un progrès par rapport à du Struts 1 et des JSP, mais personnellement je crois que JRuby on Rails a plus de sens. En effet, ça fait tourner le vrai Rails inchangé avec vraiment presque tous ces plugins (sauf de rares ayant des dépendances natives pas encore portées en Java), Rails 2.0 et ses nested resources URL si restful...
On peut bien y utiliser une persistence Hibernate (avec ActiveHibernate par exemple ou directement) si vraiment on ne trouve pas son bonheur avec ActiveRecord sur les drivers JDBC. On peut aussi facilement appeler tout beans Spring pour y intégrer du J2EE à papa. On peut aussi bien sur appeler n'importe quel javabeans directement depuis le code JRuby et échanger avec, disons que Spring c'est just pour mieux gérer l'IOC legacy, en Ruby on peut faire plus simple et plus élégant.
Grails c'est aussi la language Groovy dont les rumeurs sur les performances ne sont pas très bonnes; je crois que JRuby head fume bien Groovy. Sans compter que la génération de bytecode de Groovy est lente. Par ailleurs je ne crois pas que Groovy ait de compilation Just In Time comme JRuby dont c'est la force principale...
Un des rares avantages transitoire de Groovy est qu'on peut appeler depuis Java des classes implémenter en Groovy et qu'elles sont de vraies classes Java. Mais un compilateur extra de JRuby vers Java va aussi se rapprocher de ceci très rapidemment. En gros il va aussi permettre de type (optionnellement) des objets Ruby pour le cas ou on les utilise depuis Java...
Bref JRuby on Rails vaut le coup d'oeil, on se rapproche d'une maturité suffisante pour de la prod. Venez trainer sur #jruby si vous voulez en savoir plus, ça foisonne d'idées et de talents...
Raphaël Valyi.
[^] # Re: Oui mais Grails c'est aussi Groovy...
Posté par cstar . Évalué à 1.
Et JRuby on Rails 2.0 est extrêmement abouti. D'ailleurs Raphaël, tu avais commenté sur mon (ancien) blog là dessus : http://www.cestari.info/2007/7/2/jruby-1-0-premi-egrave-re-e(...)
Et depuis, la performance et la consommation mémoire s'est beaucoup améliorée.
Cette appli JRoR devrait sortir très bientôt, contenue dans GlassFish. Et les performances sont là.
Bref, y a de la place pour Grails, mais entre JRoR et Django on Jython, va falloir la jouer fine ;)
# Lift
Posté par Ummon . Évalué à 3.
Ce projet est pour l'instant assez jeune mais progresse très rapidement, voici le site officiel : http://liftweb.net/
PS: Je sais que les micro-benchmarks ne sont pas forcément significatifs mais ça fait quand même peur : http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?t(...)
[^] # Re: Lift
Posté par benja . Évalué à 2.
# Grails ... bof
Posté par Miguel Moquillon (site web personnel) . Évalué à 3.
Ce que je peux dire, c'est que, comparé à RoR, je le trouve moins bien avancé/pensé. Exemple de la convention de mapping entre base de données et classes du domaine : dans RoR, un many-to-many à représenter par une table de jointure peut-être défini en tant que migration dans db/ ; donc pas de pollution du domaine... Dans Grails la jointure doit être représentée par une classe du domaine (ou alors faut se palucher les .hbm d'hibernate, donc on perd de l'intérêt de grails). Ceci n'est qu'un petit exemple parmi tant d'autre.
De plus, je confirme nettement rvalyi sur la lourdeur de groovy et sur les perfs de JRuby (pour l'avoir aussi utilisé) comparé à groovy. J'ai bien peur que la montée en charge d'une application Grails soit pour l'instant bien en deçà d'une application RoR et donc d'une application Web Java (JEE / spring).
Je voudrais aussi écrire que Grails, comme RoR, se positionne sur un marché différent des applications serveurs/web java "classiques" (JEE / spring). Ces derniers se positionnent sur la mise en oeuvre d'applications serveurs de classe entreprise (les grosses appli en résumé). Grails et RoR se positionnent plus sur le marché des petites et moyennes applications web ; ils sont, je pense, idéal pour concevoir une appli web perso (en lieu et place de PHP) qui prend pas la tête et qui soit facile à faire évoluer. Aujourd'hui, si je devais choisir entre RoR et Grails, je choisirais RoR (je trouve, pour les avoir utilisé tous les deux, que le langage Ruby est bien supérieur à Groovy, et de même le framework RoR vis à vis de Grails).
Maintenant, pour ceux qui recherchent un langage de script pour la JVM et que ne veulent pas utiliser Ruby (JRuby), je conseillerai de regarder plus du côté de Scala que de Groovy.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.