Taller de Grails

4,810 views
4,675 views

Published on

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

Published in: Technology
1 Comment
8 Likes
Statistics
Notes
  • Excelente explicación... estoy realizando un postgrado y primera vez que tengo una aproximación a este lenguaje. Yo estoy acostumbrado a PHP y MySQL... espero poder aprender a utilizar Grails.. Gracias por el tutorial...
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
4,810
On SlideShare
0
From Embeds
0
Number of Embeds
193
Actions
Shares
0
Downloads
0
Comments
1
Likes
8
Embeds 0
No embeds

No notes for slide

Taller de Grails

  1. 1. Taller de Groovy & Grails<br />13 Reunión de SpringHispano.org<br />
  2. 2. Twitter<br />Por favor para comentar en Twitter usa el hashtag#sh13<br />No se te olvide revisar los tweets con ese hashtag ;-)<br />
  3. 3. Grails<br />Una plataforma para el desarrollo Web<br />
  4. 4. Agenda<br />Grails<br />Introducción<br />Clases de dominio<br />Controllers<br />Servicios<br />TagLibraries<br />Deployment<br />
  5. 5. Introducción<br />¿Qué es Grails?<br />Una plataforma para desarrollo ágil en Web<br />Logrando funcionalidades efectivas<br />Y de paso divirtiéndose haciendolo<br />Un framework MVC full-stack<br />Open Source<br />Corre en la JVM<br />Desarrollo de aplicaciones con Groovy<br />Altamente expresivo<br />Totalmente orientado a objetos<br />Dinámico<br />Sintaxis familiar<br />Perfecta integraciñon con Java<br />
  6. 6. ¿qué mas es Grails?<br />Convención sobre configuración<br />Defaults sensibles<br />Todo tiene un lugar<br />DRY (Don’trepeatyourself)<br />
  7. 7. Simplicidad y poder<br />IoC<br />Provee una manera de ‘alambrar’ los objetos juntos con sus dependencias para tenerlos disponibles en tiempo de ejecución.<br />IoC libera al desarrollador de la responsabilidad de obtener una referencia a un objeto dependiente<br />ORM<br />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<br />
  8. 8. Grails: la plataforma<br />
  9. 9. Grails vive en el Ecosistema Java<br />La grámaticaGroovy es derivada de Java 5, haciendo válido el código Java y el código Groovy<br />Groovy comparte las misma API’s de Java<br />Los objetos Groovy son objetos Java.<br />A través del compilador de ensamble podemos tener referencias circulares entre Groovy y Java sin tener problemas de compilación<br />Con Groovy podemos fácilmente usar las misma herramientas, las mismas herramientas de monitoreo y todas las existentes y futuras tecnologías Java <br />
  10. 10. Laboratorio 1<br />Instalación de Grails y creación de la primera aplicación<br />
  11. 11. Ventajas y características<br />ORM con Cero-Configuración<br />DependencyInjection<br />Manejador de transacciones<br />JNDI<br />Internacionalización<br />Web Flow<br />Taglibraries<br />Caching<br />REST<br />Layouts<br />AJAX<br />Servidor no necesita reiniciar(most cases)<br />Desarrollo de pruebas en caliente<br />Unit testing<br />Integrationtesting<br />Functiopnaltesting<br />
  12. 12. Clases de dominio<br />Sirven como corazón de la aplicación y del concepto del modelo de negocio<br />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<br />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<br />
  13. 13. Scaffolding<br />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<br />Importante: Grails NO es un framework para hacer CRUD. Y el scaffolding aunque es muy usado, no es el verdadero beneficio de usar Grails<br />
  14. 14. Scaffolding<br />Viene en dos sabores:<br />Dinámico<br />En runtime<br />Estático<br />Manejado por templates<br />
  15. 15. Laboratorio 1.9<br />Instalación de plugin de seguridad<br />
  16. 16. Laboratorio 2<br />Creación de clases de dominio y uso de Scaffolding dinámico<br />
  17. 17. Scaffolding estático<br />Podemos generar el código necesario del scaffolding, para estudiarlo, modificarlo, o eliminarlo…<br />Nos ayudamos de:<br />grailsgenerate-views<br />grailsgenerate-controller<br />grailsgenerate-all<br />
  18. 18. Laboratorio 3<br />Scaffolding estático<br />
  19. 19. Configurando DataSources<br />Donde se almacenan los datos actualmente???<br />Podemos cambiar el lugar donde se ubica la base de datos y hacer una diferenciación entre diferentes ambientes de desarrollo<br />Lo definimos en un solo archivo DataSource.groovy<br />Un datasource se ve:<br />dataSource {<br />pooled = true<br />driverClassName = &quot;com.mysql.jdbc.Driver&quot;<br />dialect = org.hibernate.dialect.MySQLInnoDBDialect<br />username = &quot;root&quot;<br />password = &quot;root&quot;<br />}<br />
  20. 20. Datasource<br />Lista de elementos que se pueden configurar:<br />driverClassName<br />username<br />password<br />url<br />dbCreate<br />pooled<br />configClass<br />logSql<br />dialect<br />
  21. 21. Environments<br />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:<br />environments {<br />development {<br />dataSource {<br /> …<br /> }<br /> }<br /> test {<br />dataSource {<br /> …<br /> }<br /> }<br />production {<br />dataSource {<br /> …<br /> }<br /> }<br />}<br />
  22. 22. JNDI en Datasource<br />Podemos configurar un recurso JNDI en el datasource de manera muy simple:<br />production {<br />dataSource {<br />jndiName=“java:comp/env/jdbc/database”<br /> }<br /> }<br />
  23. 23. Entendiendo mejor las clase de dominio<br />Las aplicaciones OO por lo general siempre involucran un modelo de dominio representando las entidades de negocio de la aplicación<br />Grails hace mucho del trabajo ‘díficil’<br />Por default todos los atributos de la clase son persistidos a base de datos<br />
  24. 24. Validando las clases de dominio<br />Muy seguramente encontremos reglas que obliguen a validar los valores de ciertas propiedades en una clase de dominio<br />Reglas como estas deben ser expresadas claramente y solamente en un lugar<br />Grails provee un mecanismo de validación a través de la interfaz Validation de Spring<br />classPerson{<br />String propiedad<br />staticconstraints = {<br />propiedad(blank:false)<br /> }<br />}<br />
  25. 25. Lista de restricciones para clases de dominio<br />
  26. 26. Otras restricciones<br />min<br />minLength<br />minSize<br />matches<br />max<br />maxLength<br />maxSize<br />notEqual<br />Nullable<br />range<br />scale<br />size<br />
  27. 27. Propiedades transitorias<br />Por default cada propiedad es persistido en base de datos, sin embargo, hay veces que una propiedad no debe ser persistida por requerimiento funcional<br />Grails provee un mecanismo muy sencillo para para especificar que propiedades pueden ser transitorias<br />Se hace como sigue:<br />classCompany{<br />String nombre<br />BigDecimalsalarioPorDepartamento<br />statictransients = [&apos;salarioPorDepartamento&apos;]<br />}<br />
  28. 28. Personalizando el mapeo de base de datos<br />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<br />Con ayuda de un DSL Grails me permite cambiar este comportamiento<br />
  29. 29. Personalizando el mapeo de base de datos<br />La clase:<br />classPerson{<br />StringfirstName<br />StrinlastName<br />Integerage<br />}<br />Genera:<br />Table: person<br />Fields: idbigint,versionbigint, ageint, first_namevarchar(255),last_namevarchar(255)<br />Supongamos que tenemos:<br />Table: people<br />Fields: person_idint, person_ageint, person_first_namevarchar(255), person_last_name(255)<br />
  30. 30. ¿Cómo lo mapeamos?<br />classPerson{<br />StringfirstName<br />StrinlastName<br />Integerage<br />staticmapping = {<br />table &apos;person&apos;<br />idcolumn:&apos;person_id&apos;<br />firstNamecolumn:&apos;person_first_name&apos;<br />lastNamecolumn:&apos;person_last_name&apos;<br />agecolumn:&apos;person_age&apos;<br />versionfalse<br /> }<br />}<br />
  31. 31. Relaciones entre clases<br />Típicamente tenemos clases que se relacionan entre sí para darle sentido al negocio<br />Grails me ayuda a resolver estas relaciones con el uso de relaciones basadas en OO<br />Composición<br />Agregación<br />Herencia<br />Dependencia<br />
  32. 32. Probando las clases de dominio<br />Automatizar las pruebas puede ser un proceso importante en la construcción de sistemas complejos<br />Ayudan a confirmar que la funcionalidad requerida es valida y usable<br />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<br />Grails provee de una clase llamada GrailsUnitTestCase para realizar verdaderas pruebas de unidad<br />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<br />
  33. 33. Laboratorio 5<br />Relaciones entre clases y pruebas de unidad<br />
  34. 34. Controllers<br />Es la clase responsable de manejar el request que viene de la aplicación<br />Los controllers reciben el request, potencialmente hacen algo con el request y finalmente deciden que debería pasar despues<br />Ejecutar la acción de otro controller<br />Renderear una vista<br />Renderear información directamente al response<br />Son singleton por lo cual no es necesario manejar las nuevas instancias creadas por request<br />Proveen la entrada principal a las aplicaciones hechas con Grails<br />Delegan a servicios o clases de dominio la lógica de negocio y hacen el render de las vistas<br />
  35. 35. Atributos del Request<br />actionName<br />actionUrl<br />controllerName<br />controllerUri<br />flash<br />log<br />params<br />request<br />response<br />session<br />servletContext<br />
  36. 36. Alcances usando Controllers<br />request<br />Objetos puestos en el request son guardados durante la ejecución actual del mismo<br />flash<br />Los objetos almacenados en flash tienen una duración del request actual y del siguiente request solamente<br />session<br />Los objetos guardados en session son almacenados hasta que se invalida la sesión manualmente o expira<br />servletContext<br />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<br />
  37. 37. Redireccionando un request<br />Podemos hacer que una acción de cierto controller mande a otro controller o bien a alguna parte fuera de nuestra aplicación<br />A través de redirect() lo podemos hacer y le podemos indicar:<br />action<br />controller<br />id<br />params<br />uri<br />url<br />
  38. 38. Renderear una vista<br />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:<br />classClienteController{<br />def show = {<br /> //do something<br /> }<br />}<br />En el ejemplo anterior se busca una vista dentro del directorio views/Cliente/ de nombre show.gsp (ya veremos más adelante las views)<br />Ahora si queremos cambiar la convención y mostrar otra vista podemos hacer lo siguiente<br />classClienteController{<br />def show = {<br />render(view:&quot;display&quot;)<br /> }<br />}<br />
  39. 39. Vista - GSP<br />Las vistas en el ambiente web son un topico por demás interesante<br />JSP permiten mezclar el tradicional HTML con código Java<br />Incluso podemos usar las JSTL<br />Para Grails existen las GSP<br />Las GSP proveen un mecanismo para crear tags personalizados pero sin sacrificar la agilidad<br />Las GSP son la manera Groovy en que Grails nos facilita la vida en el desplegado del modelo<br />
  40. 40. Atributos de las GSP<br />application<br />flash<br />out<br />params<br />request<br />response<br />session<br />
  41. 41. GSP esta construido sobre tags<br />Tagspre-empaquetadas<br />Logicas: if, else, etc.<br />Iterativas: while, each, findAll, etc<br />Formulario: textField, checkBox, datePicker, etc<br />Renderizado: layoutBody, paginate, etc<br />Ajax: remoteField, submitToRemote, etc<br />Y otras más<br />Tags personalizadas<br />Nombradas usando convención<br />Su nombre termina con TagLib<br />Se ubican en el directorio de taglib<br />Implementadas como closures<br />No hace falta TLD’s<br />
  42. 42. Laboratorio 7 <br />Uso de tags<br />

×