Centralización de constantes para Symfony2 y Twig

A la hora de trabajar con proyectos grandes nos encontramos generalmente con la necesidad de usar ciertos códigos o IDs (PKs) en duro dentro de la lógica de la programación. El caso que posiblemente sea el más usado, es cuando intentamos validar ciertas acciones dependiendo de los estados de los objetos.

Supongamos un caso sencillo como por ejemplo la lista de usuarios del sistema, en donde necesitamos agregar un botón para activarlos o inactivarlos de acuerdo a esta pequeña lógica:

  • Si el usuario se encuentra “activo”, el botón debería ser rojo con un texto “Inactivar Usuario”
  • Si el usuario se encuentra “inactivo”, el botón debería ser normal con un texto “Activar Usuario”

Esto por lo general se traduce en un código de lógica de presentación de una manera parecida a la siguiente, tomando en cuenta que el ejemplo se encuentra dentro de una layout de Symfony2 con twig y Twitter Bootstrap:


{% if usuario.estado == 'A' %}
    <button type="button" class="btn btn-danger">Inactivar Usuario</button>
{% elseif usuario.estado == 'I' %}
    <button type="button" class="btn">Activar Usuario</button>
{% endif %}

Continúa leyendo Centralización de constantes para Symfony2 y Twig

Enviar logs a un syslog centralizado con Symfony2 y Monolog

Recientemente me vi en la necesidad de enviar los logs de un sistema hecho con Symfony2 al syslog de la empresa y la sorpresa es que ni en la documentación de Symfony ni en la documentación de Monolog hay mucha información sobre este tema, así que voy a ver de documentar las pruebas aquí para que sirva de referencia a quiénes lo intenten.

La configuración de monolog en Symfony es un poco confusa, no tanto por como configurarlo sino porque hay que conocer varios conceptos e ir probando.

En uno de los cookbooks del sitio oficial de Symfony se puede encontrar este artículo que explica como usar diferentes handlers para tratar los logs. En el ejemplo se puede ver el siguiente código yml:

Continúa leyendo Enviar logs a un syslog centralizado con Symfony2 y Monolog

Patrones de Casos de Uso 4/9 – Known Object

Continuando con la serie de artículos sobre Patrones de Casos de Uso, hoy quiero hablar sobre el patrón KNOWN OBJECT, creado por Martin Langlands. Este patrón forma parte de la lista de Patrones del Contenido de Casos de Uso presentados en el paper del autor antes mencionado, y es más bien un concepto muy sencillo pero muy importante a la hora de describir este tipo de documentaciones.

Existen casos de uso que son directamente invocados por un actor como por ejemplo los que utilizan patrones como BASIC CREATOR o CRITERIA SEARCH. Estos tipos de casos de uso pueden ser invocados directamente porque no necesitan como pre-requisito una instancia de un objeto existente. Es decir, cuando vamos a crear un objeto, el objeto todavía no existe y cuando lo buscamos, la idea es encontrar una instancia. Por otro lado, existen casos de uso que necesitan de una instancia de un objeto ya existente como para iniciar los flujos, como serían los casos de uso para visualizar un registro, modificarlo o incluso cambiar de estado, lo que es muy común.

Como ejemplo, imaginemos un buscador de personas. Una vez encontrados los registros (objetos) que buscamos, nos dará la posibilidad de realizar acciones sobre ellos. Cada acción, utilizando la idea del patrón OBJECT MANAGER, podrá incluir un caso de uso que ejecute lo necesario. Estos casos de uso que son incluidos son lo que deberán conocer el objeto con el cual trabajar. Así por ejemplo, podemos tomar el caso de visualizar los datos de la persona, modificar sus datos, activar a la persona o inactivarla. Cuatro casos de uso que necesitan, como pre-requisito, saber sobre cuál persona deben realizar sus acciones.

Continúa leyendo Patrones de Casos de Uso 4/9 – Known Object

Patrones de Casos de Uso 3/9 – Property List

Ya hemos visto dos artículos sobre Patrones de Casos de Uso orientados al diseño tomando como referencia el paper publicado por Martin Langlands. En este artículo vamos a hablar sobre el patrón PROPERTY LIST que se trata de como detallar las propiedades de un objeto dentro de los casos de uso que lo necesiten. Es decir que este patrón en realidad no tiene que ver directamente con las acciones de un CRUD, sino que más bien formará parte de varios casos de uso en donde se necesite listar las propiedades de un objeto o los datos que necesitemos.

En resumen, este patrón será utilizado dentro de otros casos de uso que utilicen a su vez los patrones BASIC CREATOR, VIEWER/UPDATER y CRITERIA SEARCH. En estos casos de uso tenemos la necesidad de decir que propiedades queremos que el usuario cargue o modifique para un objeto, como así también cuales son los datos que nos sirven para los filtros de una búsqueda y los datos que necesitaremos mostrar en los resultados de la búsqueda.

Dando un ejemplo claro sobre esto, podríamos imaginar un caso de uso que permita crear una Persona. Cuando llega el momento de definir cuales serán las propiedades de la persona que el actor deberá cargar, necesitamos listar por ejemplo nombre, apellido, documento de identidad, fecha de nacimiento, etc; este es el objetivo del patrón PROPERTY LIST, estandarizar esta forma de listar o detallar cuales serán las propiedades. Esto mismo ocurre cuando existen filtros de búsqueda en un caso de uso Buscar Persona; o incluso cuando tenemos que mostrar información de la persona para que el actor las pueda ver.

Continúa leyendo Patrones de Casos de Uso 3/9 – Property List

Patrones de Casos de Uso 2/9 – Object Manager

En el artículo anterior hemos visto una introducción a los patrones de contenido de casos de uso presentados por Martin Langlands. Ya vimos brevemente explicados los patrones, por lo tanto a partir de este artículo, comenzaremos a verlos uno por uno, haciendo también algunas traducciones del paper original para mantener la idea de Langlands y dando mi opinión al respecto. Los patrones no serán explicados en el mismo orden que Langlands los presenta en su paper, sino que iré escribiendo los artículos desde otra perspectiva.

El primer patrón que me gustaría tratar es el OBJECT MANAGER. Este patrón, de alguna manera, agrupa a los demás patrones presentados por Langlands, y hay que recordar que estos patrones de casos de uso tratan sobre el contenido de los casos de uso y no así a cómo estructurarlos (lo que sería el concepto descrito en el paper como “Inside the Oval”). Sin embargo, este es el único patrón que trata más bien sobre como organizar los patrones de contenido presentados.

Por lo general, cuando hablamos de sistemas, hablamos de trabajar con una base de datos o alguna forma de almacenamiento de datos. Durante la etapa de análisis, cada objeto que tiene la capacidad de persistir sus propiedades en una base de datos es conocido como una entidad, y este tipo de objetos son con los que más lidiamos a la hora de la descripción de casos de uso.

Continúa leyendo Patrones de Casos de Uso 2/9 – Object Manager