Ya hace varios meses venimos trabajando con gente de Maestros del Web para crear una guía de Symfony2 y el día de hoy se ha publicado mi primer capítulo. Esta guía la escribimos en conjunto con @maycolalvarez (maycolalvarez.com) quien también es autor de varios capítulos […]
La fecha tan esperada desde hace ya mucho tiempo ha llegada finalmente. Ya estuvimos esperando desde el año pasado varias veces el famoso lanzamiento de Symfony2 y hoy ha llegado el día oficial por lo que no me gustaría dejar pasar este día tan esperado sin dejar una impresión de meses de pruebas con varios preview releases, beta versions y release candidates.
Mi primera impresión sobre esta nueva versión después de trabajar con Symfony desde la versión 1.0 es, SE ESCRIBE MUCHO!!!. La magia que hasta ahora nos regalaba Symfony 1 con sus archivos .yml eran realmente muy útiles pero lastimosamente tuvieron que sacrificar esto para lograr mayor performance.
Muchas veces busque 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.
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 devuelve de cierta manera que podamos manipularlos más fácilmente. A esta proceso de transformación se le denomina «hidratar los datos» y nos sirve para manipularlos como objetos, arrays o como un dato específico a lo que se le denomina escalar.
Este es el segundo artículo sobre la serie Parametrizando nuestro sistema con Symfony en el cual veremos como este framework puede ayudarnos a tener los datos paramétricos del sistema centralizados en un solo lugar a fin de utilizarlos de una manera más fácil y rápida.
Mucho se habla hoy en día de que un sistema parametrizado es mucho mejor que los famosos «códigos en duro» que los programadores solemos escribir dentro del fuente de los programas. Es muy normal ver gente que usa combos de selección múltiple que en realidad van cargados dentro del mismo HTML de la página. El problema ocurre realmente cuando hacemos esto con varias páginas y luego resulta muy engorroso el mantenimiento del sitio ya que hay que buscar todos los lugares en donde lo hicimos a la hora de agregar, quitar o modificar alguna de las opciones de nuestro combo. Con este artículo veremos como centralizar los parámetros de nuestras aplicaciones en un lugar y luego obtenerlos para su utilización rápida.