Taller de Grails impartido en la reunión 13 de SpringHispano,org y de grails.org.mx

1. Taller de Groovy & Grails 13 Reunión de SpringHispano.org

2. Twitter Por favor para comentar en Twitter usa el hashtag#sh13 No se te olvide revisar los tweets con ese hashtag ;-)

3. Grails Una plataforma para el desarrollo Web

4. Agenda Grails Introducción Clases de dominio Controllers Servicios TagLibraries Deployment

5. Introducción ¿Qué es Grails? Una plataforma para desarrollo ágil en Web Logrando funcionalidades efectivas Y de paso divirtiéndose haciendolo Un framework MVC full-stack Open Source Corre en la JVM Desarrollo de aplicaciones con Groovy Altamente expresivo Totalmente orientado a objetos Dinámico Sintaxis familiar Perfecta integraciñon con Java

6. ¿qué mas es Grails? Convención sobre configuración Defaults sensibles Todo tiene un lugar DRY (Don’trepeatyourself)

7. Simplicidad y poder IoC Provee una manera de ‘alambrar’ los objetos juntos con sus dependencias para tenerlos disponibles en tiempo de ejecución. IoC libera al desarrollador de la responsabilidad de obtener una referencia a un objeto dependiente ORM Provee una abstracción adicional sobre SQL, permitiendo a los desarrolladores pensar acerca de su modelo de dominio en lugar de pensar como acomodar los datos en SQL

8. Grails: la plataforma

9. Grails vive en el Ecosistema Java La grámaticaGroovy es derivada de Java 5, haciendo válido el código Java y el código Groovy Groovy comparte las misma API’s de Java Los objetos Groovy son objetos Java. A través del compilador de ensamble podemos tener referencias circulares entre Groovy y Java sin tener problemas de compilación Con Groovy podemos fácilmente usar las misma herramientas, las mismas herramientas de monitoreo y todas las existentes y futuras tecnologías Java

10. Laboratorio 1 Instalación de Grails y creación de la primera aplicación

11. Ventajas y características ORM con Cero-Configuración DependencyInjection Manejador de transacciones JNDI Internacionalización Web Flow Taglibraries Caching REST Layouts AJAX Servidor no necesita reiniciar(most cases) Desarrollo de pruebas en caliente Unit testing Integrationtesting Functiopnaltesting

12. Clases de dominio Sirven como corazón de la aplicación y del concepto del modelo de negocio El atributo más significativo que diferencia a las clases de dominio de otros artefactos dentro de las aplicaciones Grails es que estas son persistentes y que Grailsautómaticamente mapea cada clase de dominio dentro de una tabla física en la base de datos configurada El acto de mapear las clases en la capa de una base de datos relacional es también conocido como mapeo objeto-relacional(ORM). El ORM de Grails es llamado GORM y esta construido sobre el framework de persistencia más usado: Hibernate

13. Scaffolding Es una característica de Grails que permite rápidamente generar las interfaces para un CRUD para una clase de dominio existente. Ofrece varios beneficios, uno de ellos o tal vez el más destacado es que permite al desarrollador observar como interactúa Grails en todos sus elementos Importante: Grails NO es un framework para hacer CRUD. Y el scaffolding aunque es muy usado, no es el verdadero beneficio de usar Grails

14. Scaffolding Viene en dos sabores: Dinámico En runtime Estático Manejado por templates

15. Laboratorio 1.9 Instalación de plugin de seguridad

16. Laboratorio 2 Creación de clases de dominio y uso de Scaffolding dinámico

17. Scaffolding estático Podemos generar el código necesario del scaffolding, para estudiarlo, modificarlo, o eliminarlo… Nos ayudamos de: grailsgenerate-views grailsgenerate-controller grailsgenerate-all

18. Laboratorio 3 Scaffolding estático

19. Configurando DataSources Donde se almacenan los datos actualmente??? Podemos cambiar el lugar donde se ubica la base de datos y hacer una diferenciación entre diferentes ambientes de desarrollo Lo definimos en un solo archivo DataSource.groovy Un datasource se ve: dataSource { pooled = true driverClassName = "com.mysql.jdbc.Driver" dialect = org.hibernate.dialect.MySQLInnoDBDialect username = "root" password = "root" }

20. Datasource Lista de elementos que se pueden configurar: driverClassName username password url dbCreate pooled configClass logSql dialect

21. Environments Grails me permite establecer la configuración para cada entorno en el cual se ejecute la aplicación, incluso permite abrir más ambientes, esto es: environments { development { dataSource { … } } test { dataSource { … } } production { dataSource { … } } }

22. JNDI en Datasource Podemos configurar un recurso JNDI en el datasource de manera muy simple: production { dataSource { jndiName=“java:comp/env/jdbc/database” } }

23. Entendiendo mejor las clase de dominio Las aplicaciones OO por lo general siempre involucran un modelo de dominio representando las entidades de negocio de la aplicación Grails hace mucho del trabajo ‘díficil’ Por default todos los atributos de la clase son persistidos a base de datos

24. Validando las clases de dominio Muy seguramente encontremos reglas que obliguen a validar los valores de ciertas propiedades en una clase de dominio Reglas como estas deben ser expresadas claramente y solamente en un lugar Grails provee un mecanismo de validación a través de la interfaz Validation de Spring classPerson{ String propiedad staticconstraints = { propiedad(blank:false) } }

25. Lista de restricciones para clases de dominio

26. Otras restricciones min minLength minSize matches max maxLength maxSize notEqual Nullable range scale size

27. Propiedades transitorias Por default cada propiedad es persistido en base de datos, sin embargo, hay veces que una propiedad no debe ser persistida por requerimiento funcional Grails provee un mecanismo muy sencillo para para especificar que propiedades pueden ser transitorias Se hace como sigue: classCompany{ String nombre BigDecimalsalarioPorDepartamento statictransients = ['salarioPorDepartamento'] }

28. Personalizando el mapeo de base de datos Grails con el uso de convención sobre configuración mapea los nombres de las clases en nombres de campos definidos de la misma manera, sin embargo, puede que queramos saltarnos la convención por alguna necesidad especifica y establecer manualmente tanto el nombre de la tabla como los nombres de los campos, que no coinciden en la convención usada por Grails Con ayuda de un DSL Grails me permite cambiar este comportamiento

29. Personalizando el mapeo de base de datos La clase: classPerson{ StringfirstName StrinlastName Integerage } Genera: Table: person Fields: idbigint,versionbigint, ageint, first_namevarchar(255),last_namevarchar(255) Supongamos que tenemos: Table: people Fields: person_idint, person_ageint, person_first_namevarchar(255), person_last_name(255)

30. ¿Cómo lo mapeamos? classPerson{ StringfirstName StrinlastName Integerage staticmapping = { table 'person' idcolumn:'person_id' firstNamecolumn:'person_first_name' lastNamecolumn:'person_last_name' agecolumn:'person_age' versionfalse } }

31. Relaciones entre clases Típicamente tenemos clases que se relacionan entre sí para darle sentido al negocio Grails me ayuda a resolver estas relaciones con el uso de relaciones basadas en OO Composición Agregación Herencia Dependencia

32. Probando las clases de dominio Automatizar las pruebas puede ser un proceso importante en la construcción de sistemas complejos Ayudan a confirmar que la funcionalidad requerida es valida y usable En los lenguajes dinámicos es una parte FUNDAMENTAL para desarrollar un software usable debido a la gran flexibilidad que dan estos, pues no es la misma respuesta que se da en compilación que en tiempo de ejecución o simulación Grails provee de una clase llamada GrailsUnitTestCase para realizar verdaderas pruebas de unidad Incluso cuando generamos una clase de dominio a través de la línea de comando vemos que nos genera la prueba de unidad respectiva para esa clase

33. Laboratorio 5 Relaciones entre clases y pruebas de unidad

34. Controllers Es la clase responsable de manejar el request que viene de la aplicación Los controllers reciben el request, potencialmente hacen algo con el request y finalmente deciden que debería pasar despues Ejecutar la acción de otro controller Renderear una vista Renderear información directamente al response Son singleton por lo cual no es necesario manejar las nuevas instancias creadas por request Proveen la entrada principal a las aplicaciones hechas con Grails Delegan a servicios o clases de dominio la lógica de negocio y hacen el render de las vistas

35. Atributos del Request actionName actionUrl controllerName controllerUri flash log params request response session servletContext

36. Alcances usando Controllers request Objetos puestos en el request son guardados durante la ejecución actual del mismo flash Los objetos almacenados en flash tienen una duración del request actual y del siguiente request solamente session Los objetos guardados en session son almacenados hasta que se invalida la sesión manualmente o expira servletContext Los objetos que se guardan aquí son vistos a lo largo de toda la aplicación, y vivirán todo el tiempo que permanezca arriba la aplicación

37. Redireccionando un request Podemos hacer que una acción de cierto controller mande a otro controller o bien a alguna parte fuera de nuestra aplicación A través de redirect() lo podemos hacer y le podemos indicar: action controller id params uri url

38. Renderear una vista Por convención un action dentro de un controller llama a la vista con el mismo nombre del action dentro del subdirectorio de views y la clase en cuestión, por ejemplo: classClienteController{ def show = { //do something } } En el ejemplo anterior se busca una vista dentro del directorio views/Cliente/ de nombre show.gsp (ya veremos más adelante las views) Ahora si queremos cambiar la convención y mostrar otra vista podemos hacer lo siguiente classClienteController{ def show = { render(view:"display") } }

39. Vista - GSP Las vistas en el ambiente web son un topico por demás interesante JSP permiten mezclar el tradicional HTML con código Java Incluso podemos usar las JSTL Para Grails existen las GSP Las GSP proveen un mecanismo para crear tags personalizados pero sin sacrificar la agilidad Las GSP son la manera Groovy en que Grails nos facilita la vida en el desplegado del modelo

40. Atributos de las GSP application flash out params request response session

41. GSP esta construido sobre tags Tagspre-empaquetadas Logicas: if, else, etc. Iterativas: while, each, findAll, etc Formulario: textField, checkBox, datePicker, etc Renderizado: layoutBody, paginate, etc Ajax: remoteField, submitToRemote, etc Y otras más Tags personalizadas Nombradas usando convención Su nombre termina con TagLib Se ubican en el directorio de taglib Implementadas como closures No hace falta TLD’s

42. Laboratorio 7 Uso de tags