Archive for the ‘ Doctrine ’ Category

Guía de Symfony2 – Capítulo 13 – Seguridad de Acceso

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Hemos llegado al último capítulo de esta Guía de symfony2 con la entrega del capítulo 13 publicado hoy sobre como aplicación la seguridad en el acceso a nuestras aplicaciones.

Una de las cosas que siempre me gustó de Symfony es que ya tiene incluido un soporte muy interesante para la autenticación (login) y la autorización (perfiles o roles). Considero que esta es una tarea muy tediosa cuando la tenemos que hacer a mano mientras que con Symfony ya tenemos toda una arquitectura estándar para trabajar sobre ella.

Para ayudar a entender estos conceptos @maycolalvarez ha creado un ejemplo para hacer un login de usuarios y permitir/denegar acceso a usuarios según roles.

Es muy importante saber que hay Bundles ya creados que ayudan a facilitar más este tema de gran importancia como el FOSUserBundle, el cual animo a los lectores a investigar y decidir cual sea la mejor forma para cada uno.

Guía de Symfony2 – Capítulo 10 – Validación de datos y creación de formularios

VN:F [1.9.22_1171]
Rating: 4.3/5 (3 votes cast)

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.

Guía de Symfony2 – Capítulo 9 – Manipulando datos con Doctrine

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

Un nuevo capítulo lanzado de la guía de Symfony2 publicado en Maestros del Web. En esta entrega les hablo sobre como podemos manipular datos en nuestra base de datos utilizando Doctrine.

Hablamos en primer lugar sobre en Entity Manager quien se encarga de tratar con los datos y proveernos de esa abstracción. Hablamos sobre los métodos para obtener datos y cumplir las acciones de un CRUD. También y como parte principal hablamos del DQL que nos permite ejecutar SQL sin pensar en el motor ya que son operaciones sobre objetos y utilizamos el repositorio para separar la lógica de las acciones de las interacciones con la base de datos. Por supuesto todo esto lo vemos con ejemplos para plasmar con más claridad la teoría.

Si pensáramos nuevamente en la arquitectura Model-View-Controller (MVC) estaríamos viendo que la presentación de los datos (View) se encuentran en las plantillas, la programación del modelado de datos y trabajo con los mismos (Model) se encuentran en las Entidades y Repositorios.

Por último nos queda la lógica de la aplicación (Controller) que se mantendrá dentro de los actions programados dentro de cada Controlador. Esto al mirarlo desde un enfoque de arquitectura de software demuestra un proyecto muy ordenado y por sobre todo con facilidades de mantener y escalar a futuro, con un equipo de desarrollo donde cada quién maneja su parte. Algo que siempre suelo decir es que si una página llega a tener más de 20 líneas de código es porque nos estamos olvidando de modularizar y es probable que una de las partes del MVC no se encuentre en el lugar correcto.

En el siguiente capítulo, el último orientado al modelado, hablaremos sobre la validación de los datos que Doctrine nos proporciona y sobre como Symfony nos ayuda a crear objetos de tipo formularios para que los usuarios finales interactuen con la aplicación.

Guía de Symfony2 – Capítulo 8 – Configurando nuestra base de datos

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)

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.

Servicios REST usando Silex micro-framework 2/3

VN:F [1.9.22_1171]
Rating: 4.7/5 (3 votes cast)

Dando continuidad al artículo anterior sobre servicios REST usando el micro-framework Silex, hoy hablaremos sobre la implementación del código que fue publicado en GitHub como base de este proyecto.

NOTA: En este artículo veremos lo esencial del código usado para este proyecto pero se aconseja primeramente una lectura de la documentación oficial de Silex. En caso de conocer como funciona Symfony2 esto te será muy familiar.

Objetivo y alcance del Proyecto

El proyecto que usaremos se basará en crear una tabla de comentarios y realizar servicios REST para lograr un CRUD (create, read, update, delete) de la misma.

NOTA: La sentencia SQL para crear la tabla y otras utilidades las podrán encontrar en la WIKI del proyecto cuya dirección se encuentra en el archivo README.md en la raíz del proyecto.

Tendremos 4 servicios REST definidos en el proyecto: Leer mas

Data Hydrators con Symfony 1.4 y Doctrine

VN:F [1.9.22_1171]
Rating: 5.0/5 (2 votes cast)

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