Hace poco he encontrado el “primer framework CSS orientado a objetos” como lo nombra a sí mismo Anton Pawlik su autor, http://xcss.antpaw.org/ y que hace precisamente eso,…sin embargo ha tenido mucho éxito

A pesar de su sencillez, (la clase principal no es muy complicada) no se diferencia demasiado de la que escribí basándome en otra al mismo tiempo…aunque no la he llegado a usar como programador php…

Acabo de leer un artículo de Ivo Jansch, un profesional de Oracle diciendo que empresas de todos los tamaños tienen la necesidad de portar las aplicaciones de escritorio que usan bases de datos Oracle a aplicaciones web ,según nos dice, por la gran facilidad, usan un framework: ATK Framework.

El tesoro de este framework es la gran facilidad para crear administradores con sólo varias líneas de código, y es algo que me ha gustado bastante, podéis comprobarlo en su web.

Es justo la parte débil de zenphp.

Sin embargo, echando un vistazo al código vemos que realmente sí que son más líneas, porque se van definiendo los menús y sus accesos, se usan nodos de tipo atkNode, y como suele pasar con los frameworks gigantescos, tenemos que empezar a conocer la extensa terminología única de ATK:

—-
/**
* This node is new. It is used to edit profiles. A profile is a set of user
* privileges. In this scenario, each user has one profile (many-to-one
* relation).
*/
useattrib(“atkdummyattribute”);

/**
* The profileattribute can be used to edit the privileges.
*/
useattrib(“atkprofileattribute”);
—-

etc.

Son todas estas distracciones las que he intentado eliminar, por eso zenphp no tiene instalación, al copiarse ya se puede utilizar.

Y hacedme caso, no necesitáis escribir un framework completo para escribir una buena herramienta de administración, sobre todo tan reducida como la de ATK. Si queréis ver algunos ejemplos, mirad en http://programadorphp.org

Cuando estamos manteniendo una aplicación web suele ocurrir que el usuario final nos pide cambios que rompen el esquema inicial de la misma, es decir, se quieren saltar todas las reglas del diseño en el que nos habíamos “partido los cuernos” de forma que fuera todo fácilmente mantenible y estable asi como escalable.

En estos momentos tenemos dos opciones: cabrearnos mucho y quejarnos con el usuario para que lo haga a “nuestra manera o carretera”, o bien, mucho mejor, que la prioridad forme parte de todo este asunto.

Es ahora cuando decidimos que la segunda opción favorece nuestro trabajo de forma que podemos ir todavía más un paso adelante, es decir, si después de realizar todas las tareas necesarias para generar una página de una aplicación el contenido generado requiere un cambio de última hora, podemos utilizar una prioridad para construir/destruir dicho contenido. Un ejemplo es utilizar CSS, la prioridad se establece con la opción “!important” ,entonces, si en el HTML de nuestro primer diseño de la web tenemos un listado de hoteles y necesitamos que en uno de los hoteles del listado se muestre una división de forma distinta, simplemente vamos a permitir que en el editor HTML WYSYWYG se puedan introducir etiquetas de estilo: <style> [ extended_valid_elements: "style" en tinymce ]y ahora vamos a reescribir la regla donde se necesita que se muestre de otra forma el contenido, en lugar de cambiar toda la lógica de la programación, entonces ,usando “!important” al lado de las reglas, por ejemplo para el ancho :

<style> #midivision { width: 350px !important;} </style>

de esa forma le damos prioridad a esta regla, lo mismo se puede hacer con javascript y el argumento “defer” de la etiqueta <script>, y lo mismo se puede utilizar en PHP si especificamos el orden de carga de las clases, etc etc.

En principio, parece que el título del post es algo de lo más paradójico, pero nada más lejos de la realidad, en zenphp siempre hay un Joker, y éstos son los trucos que enseño en este blog, triquiñuelas rápidas y complejas pero fáciles de entender y modificar en poco tiempo.

Al escribir clases que reutilizan el código de un modelo de datos de zenphp, uno se da cuenta de la facilidad con la que se pueden realizar ciertos aspectos técnicos como los filtrados de datos avanzados, de una forma realmente sencilla: en una línea de PHP.

Veamos como podemos diferenciar cuando un usuario manda un fichero mediante un modelo de datos (y su interfaz: el visualizador HTML) flash o una imagen y después representarlo con la plantilla que sea adecuada.

El campo imagen tiene el nombre del fichero .jpg,.png,.gif, o bien .swf. por lo tanto sólo tenemos que escribir una función donde queramos, por ejemplo, en mi caso me gusta ponerlas en el visualizador ya que el filtrado devuelto es una cadena HTML que escribe el ‘<img src=”…”>’ o bien el HTML del código flash en javascript o el objeto que sea…

Veamos la función:

function detectar_imagen_o_flash($campo){
  if (strtolower(substr($campo,-3,3))=="swf"){
   $p = new zen_plantilla("flash/producto.html");
   $p->reemplazar("flash",substr($campo,0,strlen($campo)-4));
   return $p->contenido;
  } else {
   return '<img src="/media/img/productos/'.$campo.'">';
  }
 }
?>

Ahora, desde donde queramos podemos llamar al modelo de datos donde está la imagen y representarla por medio de su visualizador html, por ejemplo, desde el visualizador html principal de la aplicación de nuestro sistema, donde hemos definido el modelo de datos en una variable llamada $productos en la aplicación, por lo tanto las dos líneas que necesitamos son:

$this->padre->productos->filtros_postprocesamiento = array(“imagen” => array($this->padre->productos->html,”detectar_imagen_o_flash”));

$this->c['contenido'] = $this->padre->productos->html->mostrar($datos[1],”productos/ver_producto.html”);

La primera especifica para el padre de este visualizador html de la aplicación, en su variable productos que es el modelo, los filtros para después de cargar los datos de una tupla, al campo imagen le vamos a pasar el filtro de la función que hemos creado en el paso anterior, pero tenemos que especificar dónde está desde aquí, la ruta por la jerarquía de nuestra aplicación es tan sencilla como ir al padre luego al modelo y a su visualizador, allí está la función.

La segunda línea guarda en el array de contenido (puntero al array de la aplicacion->contenido) en la etiqueta del contenido de nuestra web, la visualización de datos de una tupla especificada por el id numérico que es la llave principal de la tabla del modelo de productos y le decimos la plantilla que vamos a usar, donde habrá un hueco para el campo llamado “#imagen#”.

Y así concluye este ejemplo, algo tan sencillo puede verse funcionando.

Al detectarse una imagen ,se muestra <img> ,si es un flash se escribe el <object> con un <script>.

A triunfar!!

Si tenemos nuestra aplicación web montada, lo único que tenemosque hacer es configurar los activadores (rutas de .htaccess de Apache) de las acciones (funciones PHP) de los modelos (clases PHP que extienden de zen_modelo_datos) de datos o las funciones de los visualizadores (clases PHP) de forma que podemos incluso crear nuestra propia gramática: loquesea.es/hablar/con/Manolo –> nos contactaría con Manolo

Ejemplo

Como siempre, veamos un ejemplo para comprender mejor la idea:

Tenemos una aplicación (zen_aplicacion) instanciada en index.php con la variable $app , ahora ,dentro de esta hay un visualizador por defecto llamado html_aplicacion en $app->html, bien, pues ahora sólo tenemos que decirle a Apache que nos redirija las entradas de direcciones con un .html al final, a las funciones de $app->html , como por ejemplo: Una típica función para ver un producto:

* En tu .htaccess (después de poner “Options +FollowSymLinks” y “RewriteEngine on” ):

RewriteRule ^productos\/(.*)\.html index.php/ver_producto/$1/

Con esta regla se llama a index.php donde se instancia $app y se llama a $app->enrutador->delegar() que analiza el resto de la dirección, es decir, productos/fichero.html…de forma que llama a la función productos ,si no existe llama al modelo con nombre productos, en nuestro caso es una función del visualizador de la aplicación (más sencillo),

Código

* Esto es lo único que tiene la función

echo $this->plantilla->devolver_contenido(“productos/”.zen_sanar($datos[1]).”.html”);

si queréis ser más profesionales, crear una plantilla HTML y meterle los datos usando las #etiquetas# ya explicadas en otros posts, asi como hacer comprobaciones de existencia del fichero .HTML y poner una plantilla tipo producto_inexistente.html si no se encuentra… (típico)

$p = new zen_plantilla();
$this->c =& $this->padre->padre->contenido; //array de contenido de la web
if ($p->cargar(“productos/”.zen_sanar($datos[1]).”.html”))
$this->c['contenido'] = $p->devolver_contenido(“productos/”.zen_sanar($datos[1]).”.html”);
else
$this->c['contenido'] = $p->devolver_contenido(“productos/no_encontrado.html”);
parent::index(); //Muestra la plantilla base_web.html y reemplaza etiquetas, etc.

Y así tendréis algo como lo siguiente:

http://www.empresayjuventud.com/productos/frescos/sandias.html

Seguramente ,se puede hacer mucho más fácil, pero ,también seguramente habrá alguien por ahi que lo escriba, saludos!
El conjunto de administración está siendo terminado, espero poder publicarlo pronto…

En la imagen se puede ver el visualizador HTML donde el único HTML que hay son pequeños mensajes de resultados, una pregunta, una confirmación, cosas simples, que han de estar mejor en funciones que lean una plantilla por defecto, asi está todo bien organizado. El resultado es una página de administración para mantener el contenido de una aplicación web cliente de forma que cualquier usuario pueda modificar cualquier parte de la misma.

Las primeras pruebas las estoy utilizando para proyectos simples y en los que me baso para ir mejorando poco a poco.

Asi es como se puede extender un proceso de automatización sin riesgos.

Ahora estoy aprendiendo un poco de ASP, y creo que me va a resultar difícil encontrar un SGC de código libre en condiciones…:P

Ahora es el momento de introducir el CMS (Content Management System en inglés) de zenphp. Echando un vistazo rápido al sistema gestor de contenidos que usa cualquier software libre que hay ahi afuera como Drupal, Joomla, Wordpress,Mambo,etc. es fácil comprobar que se utilizan para almacenar, indexar y buscar texto y contenido multimedia; estos sistemas son extremadamente útiles en sitios web donde el contenido es mantenido por más de un autor aunque muchos de ellos no dispongan de un gran abanico de conocimientos técnicos ya que pertenecen a distintos departamentos.

El Problema

Si en un sitio web hay un equipo de excelentes escritores tanto así como de diseñadores gráficos, que actualizan regularmente contenidos de diversa índole, apareciendo estos indexados en la página principal divididos parcialmente por cada una de sus categorías, debemos permitir que cada profesional se dedique a hacer lo que mejor hace, concentrándose en su área, pero trabajando juntos en el mismo sistema rápido y colaborativo.

Requerimientos de la solución

• Simplicidad : cada trabajador concentrado en su especialidad
• Permitir a los escritores editar,revisar las historias y decidir cuáles se van a publicar y cuáles van a ir a primera plana, etc.
• Uso de un sistema de plantillas consistente
• Permitir a los escritores acceder sólo a las áreas para las que fueron designados
• Permitir cambiar la apariencia en cualquier parte del sitio
• Sistema de seguridad: passwords para artículos y contenido,etc.
• Comunicación: sistema de mensajería interno (¿ajax?)

Sistemas existentes

Como todo buen programador debe preguntarse antes de ponerse a programar directamente si algo de lo que necesita posiblemente ya esté hecho, en el caso de los SGC (CMS) nos encontramos con que existen muchísimas alternativas, he analizado y participado para la mayor parte de ellos, contribuciones de OsCommerce(http://www.pionono.es), módulos para Joomla ( http://www.intecna.es/ ), adaptaciones de zenphp para PHProjekt [ver], etc

Tras evaluarlos decidí, hace un tiempo, escribir el propio para zenphp para obtener la flexibilidad con un coste añadido: muchísimo trabajo xD, pero la rentabilidad está en que ahora podemos decidir como será la salida del CMS con una interfaz mucho más amigable y cómo se integra éste en el framework dentro de un sitio web, dando la libertad de ser usado o no, aunque depende de si se realiza un correcto manejo del contenido dinámico…

Uno de los principales objetivos de un SGC (CMS) es la flexibilidad a la hora de mostrar la salida, pero suele fallar en cuanto al diseño de un flujo de trabajo particular, recordemos las cadenas de procesamiento del framework Seagull o la preparación de la “pista de raíles” de PHP On Trax, o incluso de las funciones “forward” sobrecargadas de funciones de controladores de frameworks como Symfony.

Escribir un CMS simple no requiere demasiado tiempo, mientras más avanzado y complicado sea el diseño, asi afectará a la adopción del sistema.

Sistema propuesto

En zenphp el CMS es una aplicación, realmente podemos implementar un Sistema Gestor de Contenidos si así lo deseamos, con las herramientas que ya dispone, si queremos…

• Editar contenido: desde la llegada de los editores WYSIWYG (What You See Is What You Get [auque no siempre xD ]) los SGC se han extendido como la pólvora en tiempos de guerra…Un ejemplo evidente es TinyMCE, usado para escribir este mismo artículo en Wordpress…ha mejorado tanto que no osaría compararlo con las primeras versiones de administraciones que empezamos a construir
• Insertando contenido: administradores de ficheros, librerías de imágenes y vídeos, gestores de subidas de ficheros en Perl y AJAX, qué más podría decir…
• Bases de datos versus sistema de ficheros: evidentemente gana el segundo, MySQL no es Oracle xD y se hace realmente tedioso trabajar con campos tipo BLOB para almacenar binarios, haciendo al sistema reducir el rendimiento, al menos tampoco tiene la licencia de Oracle
• Estructuras de documentos como base: son historias de ejemplo para “enseñar” a utilizar los sistemas gestores de contenidos, una delicia!
• Usar metadatos: hoy en día es imprescindible para hacer páginas amigables con buscadores…
• Formateando la salida: usar las plantillas por defecto
• Diseñando la base de datos y casos de uso: se pueden usar los ejemplos dados con zenphp
• Buscador: aprovechar clase de búsqueda de zenphp.
• Generador RSS: existente
• Bloqueador de spam: presente
• Exportador de documentos ,artículos a PDF: viable
• Caché: incluida
• Compactador: funcionando
• URL’s amigables con buscadores: enrutada!

Extras:

• Usar cosas “raras” avanzadas: procesadores de plantillas XCS: PHP+CSS
• Eliminar cuellos de botella de aplicaciones web 2.0 con frameworks javascript y macros ajax.

El framework proporciona lo necesario para consturir un sistema gestor de contenidos, disfrutadlo