Archive for octubre 2010

Parametrizando nuestro sistema con symfony 2/2

VN:F [1.9.22_1171]
Rating: 4.0/5 (4 votes cast)

Continúo con lo prometido de seguir con el artículo Parametrizando nuestro sistema con symfony con este segundo artículo sobre esta serie. Aquí veremos como implementar con Symfony unos métodos que nos hagan un poco más sencillo el desarrollo de una aplicación parametrizada.

Habíamos visto en el artículo anterior que podríamos trabajar creando una tabla en la que centralicemos los parámetros de nuestra aplicación según dos puntos importantes.

  1. Cantidad de registros : Si la cantidad de registros es relativamente fija y no crecen tan variablemente como son las tablas transaccionales.
  2. Cantidad de columnas: Si estas tablas tienen exactamente 2 columnas como generalmente serían id y nombre.

De esta manera lograríamos no tener tantas tablas que simplemente las usamos como parámetro y hacer nuestra aplicación mucho mas fácil de mantener.

En éste artículo veremos como manipular los datos de la tabla parámetro de una forma en la que no necesitemos mucha conversación con la base de datos.

Leer mas

Parametrizando nuestro sistema con symfony 1/2

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

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.

Mucha gente acostumbra crear tablas paramétricas para por ejemplo “estados”, “paises”, “tipos”, etc. Considero, y es una opinión muy personal, que cuando estas tablas son creadas habría que analizar 2 puntos a fin de determinar si las mismas podrían ir dentro de la estructura que voy a proponer con este artículo.

  1. Cantidad de registros : Si la cantidad de registros es relativamente fija y no crecen tan variablemente como son las tablas transaccionales.
  2. Cantidad de columnas: Si éstas tablas tienen exactamente 2 columnas como generalmente serían id y nombre.

Cabe mencionar que creando tablas como las descriptas arriba vemos un crecimiento muy grande en el número de tablas de la base de datos y por supuesto un Diagrama Entidad Relación (DER – ER) muy complejo para graficar ya que la mayoría de las tablas suelen ser de este tipo.

Tomando en cuenta esto, propongo que trabajemos con una tabla a la cual denominaremos “parametro” y con la ayuda de Symfony y los artículos de la serie Personalizando el objeto sfUser de Symfony veremos como centralizar los datos paramétricos dentro de un solo lugar y los almacenaremos dentro de la sesión del usuario activo del sistema.

Leer mas

Extendiendo el sfActions de Symfony 2/3

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

Mensajes al usuario

Habiendo visto la primera parte de esta serie Extendiendo el sfActions de Symfony con el primer artículo, en el que vimos básicamente las primeras configuraciones que deberíamos hacer creando una clase BaseActions que extendiera de sfActions y haciendo que nuestros actions extiendan directamente de nuestra clase base, ahora podemos pasar a ver un ejemplo muy frecuente de uso, basándonos sobre el objeto myUser del cual hablamos en la serie Personalizando el objeto sfUser de Symfony.

Lo que hicimos en el myUser fue básicamente, para recordar, un método que permitiría cargar dentro del objeto Flash los mensajes de INFO, WARN y ERROR para los usuarios. Nos quedó algo así:

–>/apps/frontend/lib/myUser.class.php

class myUser extends sfBasicSecurityUser
{
    const INFO_MESSAGE = 'infoMessages';
    const WARNING_MESSAGE = 'warnMessages';
    const ERROR_MESSAGE = 'errorMessages';

    //::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
    // METODOS PARA MANEJO DE MENSAJES FLASH
    //::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

    /**
     * Agrega mensajes al FLASH del objeto sfUser creando un array por cada tipo
     * de mensaje (myUser::INFO_MESSAGE, myUser::WARNING_MESSAGE, myUser::ERROR_MESSAGE).
     * El mensaje $msg será agregado al nivel correspondiente que por defecto será el INFO
     * @param string $msg
     * @param string $level
     */
    public function addMessage($msg, $level = myUser::INFO_MESSAGE)
    {
        //-- Obtengo el array almacenado, en caso de no existir retorna una array vacío
        $flashContent = $this->getFlash($level, array());

        //-- Controla si ya existe un mensaje igual para no insertarlo repetido
        if(!in_array($msg, $flashContent))
        {
            //- Agrego el mensaje enviado en la siguiente posición disponible del array
            $flashContent[] = $msg;

            //-- Seteo el array al Flash nuevamente
            $this->setFlash($level, $flashContent);
        }
    }
}

Ahora podemos ingresar desde nuestros actions directamente así:
Leer mas

Personalizando el objeto sfUser de Symfony 2/2

VN:F [1.9.22_1171]
Rating: 4.0/5 (1 vote cast)

Agregando inteligencia a los Flash para mensajes

Como una continuación a la serie de artículos sobre Personalizando el objeto sfUser de Symfony vamos a usar la funcionalidad “Flash” del objeto sfUser (el flash aquí no es el de adobe X-D ). Los métodos setFlash() y getFlash() en realidad usan la sesión del usuario para almacenar los datos, la única diferencia es que estos a la siguiente vez que se ejecute una redirección en la página, el mismo objeto sfUser se encarga de borrar los datos para que no permanezcan en sesión, ya que solo sirven para mostrar los mensajes una sola vez.

Con un poco de CSS podemos lograr que existan tres tipos de mensajes, trabajando un poco con los colores y algunos DIVs:

  • infoMessages: Informaciones básicas como ser “Registro grabado con éxito”, “Bienvenido usuario: Jhon Doe”, etc
  • warnMessages: Informaciones de alertas (no errores), “Usuario o clave inválida”, “El registro no pudo ser guardado por que fallo alguna validación”
  • errorMessages: Estos si son errores ocurridos en la aplicación, “No se puedo conectar a la base de datos”, “El archivo que intenta leer no existe”, etc

Por cada uno de estos mensajes vamos a crear un atributo de tipo Flash que va a contener un array para que por ejemplo si queremos mostrar más de un mensaje de tipo INFO cada uno ocupe una posición y terminemos mostrándolos todos.

Para esto vayamos al archivo %PROJECT%/apps/%APP%/lib/myUser.class.php el cual es como la extensión del objeto sfUser preparado para que lo podamos moldear nosotros, y agreguemos lo siguiente:

Leer mas