Acabo de estar mirando el nuevo modelo de datos de Joomla 1.5 junto con su controladores y vistas…es interesante sin embargo complicado y necesitas tener el manual cerca (a “mano” ) porque no sabes nada de nada al estar dentro de una vista…si estás en una vista tipo “blog” de una categoría, cómo puedes conseguir la sección a la que pertenece? En algunos foros se discute el tema, acabando por hacer un nuevo y completo módulo o extensión también llamado para cubrir las necesidades…sólo por necesitar un identificador? …como veis parece absurdo tener una división que no te da libertad y crea más confusión…

En zenphp está el modelo de datos donde están todos los datos que está comunicado con punteros con el resto de modelos de la aplicación y por otro lado está, asociado al modelo ,el visualizador, nunca perdemos nada de vista y todo es parametrizable y accesible fácilmente, casi no tenemos ni que usar el manual o la documentación…veis la pauta? notais la diferencia? ahi radica la potencia de hacer algo simple y que funciona…

Saludos!

Toma 1:Validaciones

Después de ver los vídeos de las validaciones

Toma 2: modelo de datos

De como se construye un modelo de datos con su visualizador usando el MVC modificado

Toma 3: Visualizador avanzado:

Avanzamos con el visualizador:[ver]

Toma 4: El scaffolding

y le añadimos un andamio (scaffolding):[ver]

Todo en uno: el generador

Podemos ver como el generador de aplicaciones lo hace todo en 15 segundos (o menos )[en acción] realiza nuestro trabajo más rápido que nosotros y nos permite concentrarnos en la parte importante del problema, lo que tenemos que presentar, finalmente.

Ir al vídeo

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…