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...
# Oui mais Grails c'est aussi Groovy...
Posté par rvalyi . En réponse à la dépêche Sortie de Grails 1.0. É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.