Grails Parte 01, Introducción y cómo iniciar.

Excelente post. Ahora veo lo que se busca con Groovy, mantener a la gente que piensa "Java" y que quiera extender sus horizontes sin ser tan radical (Play!).

Lo único que no me gustó de Grails (cuando buscaba un framework que fuera bien conmigo) fue el uso de Groovy, de verdad que no me pude hacer a la sintáctica Groovyera se veía cómo algo raro, ya la entiendo más y todo ahora tiene sentido.

Con un pie dentro y otro fuera.
Tengo entendido que Grails pertenece a una división de Spring, por lo que en parte es cómo "morderse a sí mismo", o más bien fuera de la programación orientada a aspectos considero que Spring Roo está en problemas. Ahora, no sé que tanto alguien haya usado Spring Roo por aquí, yo utilicé Roo hace un rato pero sólo a modo de aprendizaje y nada profesional, no sé si @benek quien creó el post o alguien más podría decirme o no que tal.

Grails es ahora parte de SpringSource. Te ofrecen Grails, Spring Roo y Spring MVC. No tienen por qué apostarle a una sola cosa, si pueden proveer distintas opciones. Es como Apache, que ofrece Tapestry, Wicket, Click y algunas otras opciones más oscuras, en paralelo a sus implementaciones de JEE estándar.

No creo que Grails vaya a desplazar a Spring Roo ni a Spring MVC. Cada uno tiene su lugar, sobre todo porque el ecosistema de Java es muy vasto y así como hay quienes pueden y quieren tomar el camino de Grails o de Play, habrá quienes quieren actualizar aplicaciones JEE existentes y la ruta más sencilla es integrar Spring MVC o puro Spring Web.

Exacto, pero por ejemplo la división si se ve entre Spring MVC y Grails; digamos Spring MVC es algo más "Enterprise" por llamarle de una manera y Grails es más apostando a por las tecnologías ágiles. Pero ¿y Roo?...En un principio se suponía que Roo era la solución para sin tener que aprender otra cosa pudieras hacer proyectos de manera más rápida, apostando a por la AOP. Aunque aquí pudiese venir la respuesta ¿que tan AOP es Grails?

Spring MVC y Roo no compiten, Roo es una herramienta RAD, con ella puedes crear y gestionar muy fácilmente proyectos basados en Spring MVC/Hibernate/AOP, aunque al final la herramienta no quede como parte del proyecto, solamente ayuda en su generación. La estructura de un proyecto generado con Roo es muy parecida a la que genera Grails.

La diferencia con Grails es que Grails es todo el paquete: La herramienta RAD, el framework MVC, el ORM y más.

Spring MVC es un solamente un módulo para la parte web, la parte que gestiona las peticiones, respuestas y las vistas. SI quisieramos empatar Grails con las demás tecnologías de SpringSource entonces sería Grails vs Spring Roo/MVC/Hibernate (aunque Hibernate no es de SS), algo así.

Valla valla valla, estoy bastante sorprendido de lo mucho que se puede hacer con tan poco, me siento emocionado y como si estuviera en la escuela nuevamente. Pero ahora me surgen muchas dudas, se puede combinar esto con Ajax? puedo ocupar los jar de java como el mysqlconector o javamail(supongo que si, pero es simplemente para confirmar)? Lo puedo trabajar con algun IDE (eclipse :P)?

Por cierto excelente aporte, buena introducción, facil de entender, ya estoy ancioso por ver la 2da parte .....

Pues de hecho me has confundido más =P.

A ver, Spring Roo entonces ¿que es, un framework ágil para desarrollo de aplicaciones o un módulo extra de Spring?...A lo que había visto/leído de Roo es que era una manera ágil de desarrollar aplicaciones web, incluyendo AOP e integrando otras tecnologías tanto de Spring cómo estándar.

Pero ahora me surgen muchas dudas, se puede combinar esto con Ajax? puedo ocupar los jar de java como el mysqlconector o javamail(supongo que si, pero es simplemente para confirmar)? Lo puedo trabajar con algun IDE (eclipse :P)?

Todo tiene respuesta de: Si. Ya que Groovy es un lenguaje que corre sobre la JVM y el código generado es a bytecode por lo que puedes usar los jars y librerías que necesites. Lo de los IDE es cuestión de buscar los plugins necesarios (el de Groovy y el de Grails); en lo personal te recomendaría usar IntelliJ IDEA ya que tiene soporte Groovy out of box. Y pues con lo de AJAX, es obvio que se puede, cualquier aplicación moderna cuenta con AJAX en menor o mayor medida, sería ilógico que no se permitiera el uso de AJAX en cualquier framework "moderno".

Cierto, de hecho estaba revisando el dir y veo que combina JQuery y entre más voy explorando más dudas me van surgiendo pero espero poder despejarlas poco a poco y en las sucesivas entregas de este tuto.

Respondo algunas de sus dudas, con lo que he resuelto por mi cuenta en Grails, y algo de lo que he visto de Roo.

Roo, como ya dijo Benek, es una herramienta para RAD (Rapid Application Development). Con unos cuantos comandos tienes una aplicación funcional con clases de dominio, vistas, etc.

Hay que tener cuidado de estar aventando la palabra ágil por todas partes, porque ya en sistemas no solamente tiene el significado del diccionario, sino que se asocia con las metodologías ágiles (o sea, decir que Roo es ágil puede dar a entender que es una implementación de alguna metodología ágil).

Si Roo usa AOP o no, y a qué grado lo use, es bronca de Roo; yo cuando vi una demo de Roo, no vi que hubiera que usar mucho AOP para programar; de hecho ni código vi en ningún lenguaje, porque era definir las clases de dominio con unos cuantos comandos y luego salían las vistas para administrar dichas clases también con un par de comandos (similar al scaffolding de Grails). Recuerdo que Roo generaba unos archivos que no eran fuente de Java sino eran otra cosa y esos son los que luego se pueden modificar para de ahí generar todo el código Java, pero creo que hasta ahí llega mi conocimiento de Roo.

En Grails probablemente se pueden hacer cosas con AOP, a la manera de Groovy, pero hasta ahora no he tenido necesidad de usar AOP (realmente he tenido muy poca necesidad de usar AOP en general).
En cuanto a dependencias externas, supongo que ya vendrá algo de esto en los siguientes artículos que haga Benek, pero mientras tanto una probadita: la configuración de una aplicación Grails incluye manejo de dependencias, tipo Maven, donde se indican las dependencias requeridas para compilar, para tiempo de ejecución y para pruebas. Ahí se incluyen los drivers JDBC y cualquier otra librería externa que se requiera usar, como lo de JavaMail.

Aunque, cuando se desarrolla en Grails conviene echar un ojo a los plugins porque hay una colección bastante extensa de plugins para Grails; uno de ellos es por ejemplo el plugin para mail, que al ver lo que hace y cómo se usa, se da uno cuenta del poder de los plugins en Grails.

En cuanto a IDE's, pues dicen que el mejor para Grails es IDEA, pero el soporte para Grails solamente viene en la versión Ultimate, que es la de paga. Spring da soporte a Grails que va mejorando constantemente, en su STS (que no es otra cosa que un Eclipse con varias cosas adicionales que le pone SpringSource, está bueno). Supongo que ese mismo soporte se puede poner en Eclipse, pero no sé qué tan complicado sea. Honestamente, es lo de menos; lo que me ha gustado de Grails es que se puede usar muy bien sin necesidad de un IDE.

Cuando aprendo alguna herramienta nueva, trato de usar un IDE de la manera más simple, sin requerir plugins nuevos, etc, para poder distinguir muy bien lo que hace el framework que estoy aprendiendo, de lo que hacen los plugins. Y con Grails he podido ya hacer bastantes cosas editando todo con puritito jEdit, con el plugin de Groovy. Esto porque con Grails se trabaja muy bien desde la línea de comando, ejecutando comandos para crear clases de dominio, controladores, vistas, etc. Y he trabajado bastante a gusto; ya luego me meteré a usar Grails con STS a ver si mejora mucho la experiencia o si es casi lo mismo (el tiempo de arranque de jEdit contra el de Eclipse es órdenes de magnitud menor).

En cuanto a AJAX, hay plugins para eso también, que facilitan muchísimo las cosas. Yo he estado usando el GrailsUI que se basa en YUI y la verdad está regalado, no he tenido que teclear una sola línea de javascript para presentar diálogos arrastrables o modales, campos de fecha con calendarios, pestañas, etc.

Para jQuery hay este plugin y este otro, eso lo encontré en una búsqueda al aventón, seguramente hay otros que pueden ser más fáciles o más complejos de usar, etc.

Lo importante es saber que un gsp de Grails puede ser tan simple como se necesite, no tiene dependencias forzosas con ninguna biblioteca o framework de javascript, a diferencia de otros (como Tapestry 5 que ya viene con Prototype y si quieres usar jQuery es un rollo cambiar). Por lo tanto puedes meter "a patín" el framework o librería de AJAX que más te guste, o ayudarte de algún plugin que facilite su uso, y de paso puedes contribuir a dicho plugin si es que no hace algo que necesites...

Es cierto lo de IntelliJ, es que cómo en la escuela tienen licencia classroom pues tengo la ultimate, pero según yo también puedes usar Grails con la community (es cuestión de encontrar el plug-in), ya que viene con soporte para Groovy y Gradle.

La versión community de IDEA solamente soporta Groovy, no Grails. La "cuestión de encontrar el plugin" es que tendrías que crackearlo o algo así, porque el soporte oficial de IntelliJ para Grails sólo viene en la versión Ultimate. Por tanto manera legal, sólo tienes soporte para Grails usando la versión Ultimate de IDEA.

Orale que chido esta!! me latio, espero saques mas ondas de estas!!! gracias por compartir :p