Fue publicado el décimo capítulo de la Guía de Symfony2 en maestros del Web y en este capítulo les hablo sobre uno de los temas que más me ha gustado de Symfony desde que empecé a trabajar con el framework: validación de los datos y la creación de formularios.

Para las validaciones hablaremos sobre los @Asserts, simples anotaciones que realizan validaciones poderosas con poco código y vemos que Symfony2 ya nos provee de la gran mayoría que necesitaremos usar.

Hablando sobre los formularios notaremos la gran diferencia de diseñar los formularios y programar los formularios por medio de clases. Me gusta decir que en Symfony, el concepto de un formulario NO es simplemente introducción de texto sino introducción de texto VÁLIDO para la aplicación, libre de los problemas que hoy se tienen al crear un formulario a mano y tener que recordar pelear con ataques CSRF, XSS, SQL Injection y cambios en caliente con herramientas como Firebug.

El sub-framework de formularios es uno de los que más me hicieron sentir la diferencia entre usar un framework y no hacerlo y todavía hay muchas otras herramientas que nos permite usar como los formularios embebidos por lo que hay bastante para aprender.

En el primer capítulo de esta guía hablamos sobre que uno de los objetivos de Symfony es plantear que cada cosa debe ir en su lugar, respetando el concepto del MVC. Con esto podemos ver que no solo podríamos tener un equipo de desarrollo, con personas expertas en cada área, trabajando con el modelado, otras con los controladores y a los diseñadores en la vista, sino que también podríamos hablar de personas que trabajen netamente en la creación de los formularios de la aplicación.

Por mi parte este es mi último capítulo para la Guía de Symfony2 pero espero que nos podamos encontrar en siguientes artículos. En el siguiente capítulo @maycolalvarez hablará sobre la integración de Ajax en nuestras aplicaciones hechas con Symfony2.

Después de una semana de descanso para dar lugar a las vacaciones por semana santa, y luego de varios capítulos bien interesantes de Maycol sobre la vista y el controlador, hemos lanzado el capítulo 8 de la Guía de symfony2.

En este capítulo les hablo sobre:

1. La conexión a la base de datos, tarea que solo implica configurar los datos de conexión.
2. Vemos las tablas que usaremos de ejemplo para esta guía basándonos en un blog.
3. Vamos directo al concepto de las Entidades o Entities dentro de nuestro proyecto que nos permite mapear cada tabla a una clase PHP y con esto,
4. Doctrine es capaz de crear el SQL necesario para generar las tablas e incluso también poder modificar las estructuras si así lo necesitamos.

Como vemos, el framework Doctrine, al tener los datos de la base de datos y de las tablas, nos proporciona un soporte muy potente para trabajar con ellas y eso que solo hemos visto la parte de creación, borrado y modificación de tablas. En los siguientes capítulos trabajaremos manipulando los datos de las tablas y le proporcionaremos aún más información a nuestras entidades para ayudarnos a validar los datos ingresados en nuestros campos.

Muchas veces busqué alguna buena documentación sobre los Data Hydrators de Doctrine más como ejemplos que simples explicaciones y luego de mucha pelea logré entenderlos bien como para trabajar a gusto con ellos por lo que me gustaría dejarlo por escrito por si pueda serles de utilidad.

Me gustaría empezar con el concepto de que son los Data Hydrators haciendo referencia a la documentación oficial de Doctrine en su sitio web.

Doctrine has a concept of data hydrators for transforming your Doctrine_Query instances to a set of PHP data for the user to take advantage of. The most obvious way to hydrate the data is to put it into your object graph and return models/class instances. Sometimes though you want to hydrate the data to an array, use no hydration or return a single scalar value.

Yo lo explicaría diciendo que Doctrine utiliza Data Hydrators para la transformación de los Doctrine_Query que usamos al momento de hacer nuestros DQLs. Es decir, un DQL generado por nosotros nos sirve para generar dinámicamente el SQL necesario para ejecutarlo contra la base de datos y nos devuelve de alguna manera información de la base de datos que por lo general lo hubiésemos denominado un ResultSet. Estos datos devueltos vienen en un formato que Doctrine maneja y los Data Hydrators nos permiten decirle que nos devuelva de cierta manera que podamos manipularlos más fácilmente. A este proceso de transformación se le denomina “hidratar los datos” y nos sirve para manipularlos como objetos, arrays o como un valor único a lo que se le denomina valor escalar. Leer mas