zenphp :: blog

¿Por qué zenphp usa un patrón Modelo+Vista+Controlador modificado?

El Modelo contiene la información de las tablas,campos y asociaciones de la base de datos, la Vista sirve para mostrar los datos del Modelo y las acciones del Controlador, éste último se asocia con los dos anteriores para “controlar” el flujo de la información y realizar las Acciones oportunas.
Sin embargo, a la hora de la verdad, necesitamos un control mucho mayor que el que nos puede proporcionar un Controlador, ¿por qué debería ser un controlador algo separado de una vista? ¿y si al final acabas haciendo el doble de trabajo para mantener ambos funcionando?, ¿crees que un controlador es una ayuda o un estorbo?…

En zenphp hay un Modelo y un Visualizador: Vista+Controlador, pongamos un ejemplo de funcionamiento:
Supongamos que tenemos la siguiente página (la de la imagen) donde el cliente dispone de una serie artículos y en un tipo de ellos, pongamos, categoría de recetas hay un campo de fecha que no queremos que se muestre, sin embargo la plantilla es general, por lo que tenemos que insertar una condición para comprobar que cuando sea del tipo “recetas” no se muestre la fecha, esto es simple, basta con hacer en un sistema de plantillas tipo Smarty:
{if $datos->tipo != “recetas”} Fecha: {$datos->fecha} {endif}
por ejemplo…luego, dependiendo del tipo de Modelo hay que modificarlo, para que sea más eficiente puesto que no necesitamos consultar la fecha y esto mejora en microsegundos (y qué?) la consulta, pero lo que si que hay que modificar es el Controlador, entonces tenemos 3 modificaciones. ¿Son necesarias las tres?

Si en un principio habíamos diseñado bien la plantilla, en el caso de zenphp sólo tendríamos que modificar el Visualizador para hacerlo igual de eficiente que en el caso de los 3 cambios puesto que el Modelo es totalmente flexible y dinámico para que desde el Visualizador con un par de cambios al Modelo (padre) se cambia la función de salida que toma la plantilla…
En mi caso no lo hice bien XD por lo tanto tengo que cambiar también la plantilla , mi HTML es
____
Fecha: #fecha#
____
Por lo tanto, lo cambio por #fecha# y en el Visualizador de tipo HTML asociado a mi Modelo,lo que hago es añadir la condición:

__________

if ($this->padre->tipo==’recetas’) $r['fecha'] =”";
else $r['fecha'] = “Fecha:”.$r['fecha'];
__________
donde padre es el modelo artículos, $r es el array de substituciones para la clase plantilla, que se rellena con una orden del tipo:
········
$plantilla->mostrar($ida, ‘mostrar_articulo.html’, $r);
········
donde $ida es el id del artículo.
Dicha función, automáticamente toma los datos del modelo y los muestra con la plantilla HTML para el id de $ida.

Sólo faltaría que ese campo no se consultara ,bastaría con añadir en la misma función del Visualizador una condición y substituir el campo por un espacio en blanco ,entonces ni siquiera haría falta la segunda condición puesto que la etiqueta #fecha# no se reemplazaría por lo tanto hemos reducido al máximo la elegancia del código junto con la eficiencia en tiempo y espacio.

En Ruby On Rails el tema es más serio:

porque necesitamos hacer una migración de la base de datos a otra versión sin el campo para ese tipo de artículo, en zenphp no hay migraciones porque el autor o sea yo, las considera una pérdida de tiempo en un servidor de producción y a la hora de la verdad es más complejo y puede acarrear más problemas puesto que los campos necesitan mantener los valores al recuperar una versión, cosa que no estoy seguro que hagan ni siquiera en Django…