Extendiendo el sfActions de Symfony 2/3

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í:

Continúa leyendo Extendiendo el sfActions de Symfony 2/3

Personalizando el objeto sfUser de Symfony 2/2

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.

Continúa leyendo Personalizando el objeto sfUser de Symfony 2/2

Personalizando el objeto sfUser de Symfony 1/2

Presentación del sfUser

Dando continuidad a los artículos de Symfony quiero mostrarles algo que fue de mucha utilidad cuando lo conseguí hacer. Para los que no lo saben el objeto sfUser es el encargado de manejar las sesiones dentro de Symfony desaconsejando completamente el uso del array superglobal $_SESSION. Este objeto maneja por dentro la sesión del usuario y a esta funcionalidad le agrega mejoras interesantes para que los desarrolladores no tengamos que sufrir tanto. Esto es lo que nos dice el manual de Symfony:

En Symfony, el desarrollador no tiene que manipular directamente las
sesiones, sino que usa el objeto sfUser, que representa al usuario
final de la aplicación.

Para acceder al objeto sfUser, o lo que es lo mismo, para obtener o guardar datos en sesión, tenemos diferentes formas de hacerlo aunque siempre invocando a este objeto. Desde cualquier action, por estar extendiendo de sfActions, podemos acceder directamente asi:

$this->getUser()

Desde el layout principal o cualquier template (incluso partials) tenemos un atajo representado por una variable que mágicamente existe llamada

<?php $sf_user ?>

Continúa leyendo Personalizando el objeto sfUser de Symfony 1/2

Extendiendo el sfActions de symfony 1/3

Introducción al sfActions

Como habrán notado cuando trabajamos dentro de un módulo tenemos que crear los templates y los actions. Cada action creado debe extender de una clase propia del framework llamado sfActions que se encuentra dentro de la carpeta lib/action/ de los fuentes de symfony. Ésta a su vez hereda de otra y van las extensiones para arriba. Esto nos da la posibilidad de heredar código para todos nuestros actions.

La idea de éste posts es crear nuestras propias funcionalidades para no estar escribiendo muchas veces la misma cosa dentro de nuestros actions y vamos a ir haciendolo de a poco de acuerdo a las necesidades que vaya teniendo dentro de mis proyectos.

Para hacer esto lo que hago es crear dentro de la carpeta lib de mi proyecto un archivo BaseActions de la siguiente manera.

class BaseActions extends sfActions
{
}

Hacemos que nuestra clase BaseActions extienda de sfActions para que podamos seguir utilizando las funcionalidades que siempre usabamos y ahora cada vez que creamos un nuevo action lo hacemos de la siguiente manera.

Continúa leyendo Extendiendo el sfActions de symfony 1/3

Helpers 1/2 – Funciones genericas

Analizando un poco sobre los famosos helpers mencionados hoy en día en la mayoría de los Frameworks orientados a la web, me pareció interesante la idea de formular alguna explicación de como crearlos a fin de que sean lo más genéricos y reutilizables posible.

Para el ejemplo tomaremos el caso de un helper capaz de crear un input de formulario de la familia de los text, hidden, password, radio, checkbox, button, submit, reset. La idea sería crear una función que genere el HTML necesario para esto. Vayamos a un primer ejemplo y analicemoslo.

function input_helper($name, $type='text', $value='')
{
    $ret = '<input type="' . $type . '" name="' . $name . '" value="' . $value . '">';
    return $ret;
}
 
echo input_helper('nombre');
echo input_helper('id', 'hidden', 1);
echo input_helper('nombre', 'text', 'John Doe');
echo input_helper('sexo', 'checkbox', 'M');

Esto podría ser de ayuda para lo que necesitamos y es super sencillo. Obligatoriamente deberíamos pasar un nombre para el input y luego opcionalmente un tipo y un valor, tomando en cuenta que si no enviamos el tipo lo tomamos como inputtext

Supongamos que necesitaremos que el helper también sirva para agregar un class para trabajar con CSS. Este ya no sería un atributo obligatorio así que debería ser opcional y lo podremos como último parámetro de entrada.

Continúa leyendo Helpers 1/2 – Funciones genericas