Alucinando con Grails

El otro día me puse a jugar con Grails, símplemente por ver de qué iba, y me he quedado alucinado.

La instalación realmente sencilla. Un zip a desempaquetar y poner un par de variables de entorno.

Luego generar una aplicación "hola mundo". Basta un comando sencillo para crear todos los directorios del proyecto, incluidos los ficheros del proyecto eclipse correspondiente.

El único código que hice para el ejemplo fue una clase groovy con un par de atributos y un controlador por defecto, que no es más que otra clase groovy con una única línea de código para poner a true una ¿variable? Y listo, ya está la aplicación "hola mundo" lista para arrancarse.

Se arranca y se arranca un pequeño servidor web de prueba con tu aplicación. Entras en el navegador y tienes una página web en la que aparece una lista de tus entidades almacendas en base de datos, con posibilidad de crear, editar y borrar dichas entidades desde el navegador, funcionando todo bonito y a la perfección.

Y eso es la primera cosa que me alucinó: Ha creado automáticamente unas tablas en una base de datos (HSQLDB por defecto) y ha creado toda la interface de usuario (web) para poder leer y modificar dicha tabla. Quizás la aplicación no es muy útil o exactamente lo que queremos, pero desde luego es una forma muy rápida de tener el esqueleto con lo básico.

Animado por este éxito, me pongo a investigar cómo se hacen dos entidades relacionadas entre sí. También es muy sencillo. Basta crearse la nueva clase groovy para la nueva entidad y poner algún atributo static "raro", que dice "hasMany", "belongsTo" y/o "mappedBy" y ya está hecha la relación. Nuevo controlador para la nueva entidad …. y nueva cosa alucinante: sin necesidad siquiera de rearrancar el servidor, se recrean las tablas, incluida la asociación y toda la interface web para manejar ambas entidades y las relaciones entre ellas.

En cuanto a la interface web, hay una por defecto para todo esto que no se ve, pero con un comando de grails podemos generarla para dejarla visible y podemos tocar en ella para modificarla o rehacerla entera a nuestro gusto.

Y ahí es donde me tropecé y me paré. No tengo ni idea de groovy ni de gsp (lenguaje que usa grails para la interface web y que imagino que el nombre viene de jsp al que han cambiado la j de java por la g de groovy), así que cualquier cambio no trivial (y muchos de los triviales) se me hace un mundo. De todas formas, parece una opción más que interesante para el desarrollo rápido de aplicaciones web. Sólo el hecho de que te puedas despreocupar casi totalmente (y digo casi sólo por precaución) de la base de datos y de su existencia, ya merece la pena.

Esta entrada ha sido publicada en grails y etiquetada como , , . Guarda el enlace permanente.

7 respuestas a Alucinando con Grails

  1. Dani dijo:

    La verdad que Grails es un proyecto muy interesante, y creo que dentro del mundo java/web tiene mucho que decir todavía.

    De lo que comentas, son algunas de las ideas sacadas de rails(CoC, DRY, Scaffold…), por eso seguro que a quien conozca rails que no le sorprenderá(si acaso los «mágicos» cambios en las tablas de la db). Aunque tal y como vas metiéndote se ve que siguen caminos cercanos pero no paralelos, vamos que no es una copia tal cual.

    De lo mejor de Grails(además de coger muchas buenas prácticas de rails) es que se basa en frameworks conocidos como Hibernate, Spring y Sitemesh; por lo que re-aprovechas mucho conocimiento, y aún así puedes empezar a trabajar con Grails sin necesidad de conocer estos frameworks o groovy.

    Sobre gsp, no es difícil, simplemente conocer un poco los tags y poco más 😉

  2. seiju dijo:

    Viniendo del mundo Java normal que a alguien le sorprenda grails (que no GRails :P), a mi lo que me sorprende (de forma negativa) son los proyectos de aplicaciones web que todavía usan frameworks Java (o lenguajes no dinámicos).

    Normalmente coincide el uso de éstos, con el hecho de ser la típica cárnica. ¿Coincidencia?

  3. Chuidiang dijo:

    Corregido (creo) GRails. He puesto Grails y no grails, que es como aparece en la web de ellos en todos sitios.

    Yo, efectivamente, vengo de java pero no hago aplicaciones web, y además ya estoy entradito en años, así que casi cualquier cosa web me suena a nueva y más si no es java o un lenguaje «tradicional» (similar a C, C++, Basic, Pascal, PHP, etc). Afortunadamente, y gracias a eso, no he perdido aún mi capacidad de asombro y curiosidad por las cosas nuevas.

    De todas formas, cada lenguaje tiene sus porqués y a la hora de elegir un lenguaje o framework para una aplicación web, supongo que deben considerarse más cosas además de la facilidad de programación. De hecho, no creo que sea lo mejor generalizar y decir que todas las aplicaciones web deben ser con Grails (o lenguajes dinámicos) y hay que excluir todos los demás lenguajes.

    Lo de las cárnicas pues sí, seguramente coincide y no es coincidencia. También supongo pasa en las grandes empresas. Grails y Groovy son tecnologías recientes y las grandes empresas tienen mucha inercia. Si no tienen una necesidad de innovar, tampoco van migrar o empezar proyectos con tecnologías aún por probar. Algo parecido pasó con ruby on rails, que también es nuevo, prometía mucho y parece ser que tiene problemas de escalabilidad.

    Se bueno.

  4. Blaxter dijo:

    Qué casualidad :), hoy justamente he estado mirando Grails como una alternativa para un nuevo proyecto que voy a empezar. No me ha dado tiempo de mirarlo más de 30min (he decidido ponerme a escribir las historias de usuario antes de meterme a elegir qué tecnología usar) pero posiblemente mañana o estos días me ponga más en serio con él.

    Por lo poco que he visto, me parece un copia casi, casi idéntica a rails. Lo cual me tira un poco para atrás, puesto que no me parece una buena señal que un framework sea copia (literal) de otro. Es decir, me parece perfecto pillar ideas de otros lados, pero copiar tal cual, lo veo más bien como una falta de ideas (e.g. Django pilla ideas de rails, pero es muy diferente), pero bueno, es muy pronto para emitir ese juicio.

    Groovy además, es muy similar a ruby (es decir, que mola bastante programar con él :P) y el poder usar el conjunto de librerías de java de forma transparente es un gran punto a favor. Yo estoy con seiju en que para una aplicación web, no tiene sentido usar lenguajes no dinámicos (como java, o yo ni me plantearía usarlo), pero para un backend de la aplicación o para usos de bajo nivel, desde luego que java, c++ u otros lenguajes son, posiblemente, una mejor opción que algo como ruby, groovy o ptython (más útiles para desarrollos más cambiantes, como desarrollo web, o para cosas más dinámicas como testing o guis).

    Bueno, estos días evaluaré más grails y a ver al final qué me decido a usar, mis alternativas son: Grails, JRuby + rails o Django 🙂

  5. Blaxter dijo:

    Después de estar hoy probándolo y leyendo, la verdad que no me ha gustado tanto como creía que me iba a gustar. Es decir, malo no es, pero conociendo ya rails, no aporta absolutamente nada, para usar algo que es idéntico a otra cosa que ya he usado (y que ahora incluso se puede usar con Jruby perfectamente en la JVM), pues va a ser que no.

    Otro aspecto que no me ha gustado absolutamente nada, es que la documentación del proyecto es realmente pésima, tanto por su calidad como por su cantidad. Lo de la cantidad podría perdonarse, pero en lo poco que hay he visto más de una vez y más de dos lo que yo suelo llamar «el pensamiento mágico», decir cosas como, «esto es así porque sino no le gusta» o «tienes que poner esto para que funcione, sino nada» (sin razonarlo ni entender el porqué), lo cual significa muy poca calidad y profesionalidad.

    En resumen, es una buena opción (casi todo lo es), pero, en mi opinión, hay mejores alternativas.

  6. Chuidiang dijo:

    Tendré que echarle un ojo al ruby-rails o algo similar. Desde lo de redmine, me ha llamado la atención. En cualquier caso, estoy seguro que no entenderé nada 🙁 pero bueno, a fuerza de cabezazos acabaré aprendiendo algo.

    De todas formas, me llama la atención que todos hablan aparentemente maravillas de estas herramientas, pero cuando te poner a rebuscar opiniones, tampoco te cuesta encontrar gente que les pone muchas pegas. Quizás sea ese el motivo que haya tantas y que no acabe de imponerse ninguna, que en el fondo, no acaban de solucionar los problemas.

    Se bueno.

  7. Dani dijo:

    @blaxter, de acuerdo con lo de la documentación, es muy «quick start» y es difícil saber las razones de porqué algo se hace así.

    Pero con lo de que es una copia literal no estoy de acuerdo, sí que de inicio se parecen «sospechosamente» 😉 pero hay algunas diferencias, a bote pronto:

    Con grails se define como es la db en las clases del dominio y con rails usando migrations.
    En rails se sigue el principio «fat model, skinny controller» y en grails «fat services, skinny controller».
    Soporte de i18n, que por fin ha aparecido «out of the box» con rails 2.2
    DSL de criteria, para casos de generar queries dinámicas bestias muy interesante.
    La integración con java donde destaca spring, no importa si un servicio está hecho con spring o es grails «puro», además de integraciones con otras librerías/frameworks a base de plugins.

    Por descontado está lo de que para un programador java la barrera de entrada es menor.

    De todas formas yo creo que todavía tendrían que coger algunas ideas más de rails, como mejorar el soporte de REST, si algo es una buena idea por qué no copiarlo/adaptarlo 🙂

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.