zenphp :: blog

Después de muchos estudios y procesos de optimización,la última medición con el profiler PHP sobre zenphp, con el tema por defecto ha conseguido reducir al mínimo las llamadas al sistema, apertura de ficheros y operaciones ineficientes, incluso usando el compactador HTML [ver clase] lo que más se lleva es la función require de zen___carga_clase() que es la función usada para, como su nombre indica, cargar clases en nuestras aplicaciones, de hecho, usando dos aplicaciones y vinculando las bases de datos entre ellas, el resultado es el siguiente:

En zenphp no existe la función “autoload()“, que es una función muy famosa en PHP5: sirve para hacer un “require” de cualquier clase cuando la instanciamos por primera vez y no está en el ámbito actual.

Esto se hace para mantener nuestras aplicaciones sin sobrecarga, así que sólo usamos lo que cada parte de nuestra aplicación necesita en cada momento.

Veamos la gráfica:

• Nos quiere decir, que mientras más clases usemos,más veces vamos a llamar a la función zen___carga_clase y con ello será más ineficiente, sin embargo no se hacen demasiadas llamadas ya que no solemos utilizar miles de clases en una aplicación pero si hasta cientos de ellas…
• preg_replace() se usa muy poco, una única vez en la salida de la plantilla y cuando la compactación está activada, asi que si vamos a utilizar mucho procesamiento HTML y mostrar muchas veces la salida de la clase zen_plantilla, entonces es mejor desactivarla…cosa no muy probable…
• Salta varias veces con la alerta E_STRICT.Hay algunas consideraciones a tener en cuenta con el tipo de error STRICT en PHP, ya que zenphp está escrito en PHP4 y PHP5…tiene características que serán eliminadas a partir de PHP6.x en adelante; …por lo tanto PHP5 intenta mostrar alertas cuando se hacen cosas como crear una variable con una referencia a partir de una función como puede ser un  constructor de una clase…son pequeños detalles pero consumen unos milisegundos de tiempo.
• La función setlocale(); se toma alrededor de un milisegundo y medio, es la última ineficiente del conjunto inevitable…como sólo es llamada una vez no la considero para mejora, ya que es más ineficiente leer todas las constantes de idiomas (en lugar de usar fichero .mo [poedit]) como se hacía en los primeros prototipos del framework…
• El resto de peticiones no se pueden considerar ineficientes…

Seguiremos optimizando

¿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?

Leer el resto de la entrada »

He avanzado con el editor PHP/GTK del generador de aplicaciones de zen php, en esta ocasión he puesto a punto el administrador de bases de datos de mySQL.
Para verlo funcionar sólo hay que crear un fichero XML donde se especifique una aplicación y la parte de configuración referente a la base de datos.

Un ejemplo se puede ver en el svn.

<?xml version=”1.0″ encoding=”utf-8″?>
<!DOCTYPE cartucho SYSTEM “./zen_cartucho.dtd”>
<cartucho>
<previsualizacion>portal/previo.jpg</previsualizacion>
<aplicacion nombre=”Portal”>
<configuracion>
<basedatos servidor=”localhost” usuario=”root” contrasena=”" nombre=”" tipo=”mysql”>
Base de datos para el Portal
</basedatos>
</configuracion>
</aplicacion>
</cartucho>
A continuación una captura del administrador mysql para PHP/GTK embebido en el editor del generador de aplicaciones.

El XML del cartucho define las base de datos, que se cargan en el generador PHP/GTK y se muestra la interfaz de administración mysql, donde se crea una base de datos llamada zenphp y una tabla en ella de usuarios con una tupla, después se hace la selección de todas las tuplas y se muestra la información…

Pues, no es lo mismo

strtolower(strpos($ruta,-3,3))

que

strpos(strtolower($ruta),-3,3)

ya que el primero pasa a minúsculas sólo 3 letras y el segundo toda la cadena que puede contener cientos o miles de caracteres y esto repetido 100 veces compromete un script de 1 a 5 segundos de promedio en lugar de tan sólo unos microsegundos, es una diferencia a tener en cuenta…

En zenphp se intenta hacer todo con el código bien escrito, es por eso que se tarda un poco más en terminar algunos puntos críticos como se tardó en escribir zen_andamio o ahora el generador pero merece la pena.
Si revisais el código del framework veréis más cosas como esta, por ejemplo, cargar el número de componentes de un vector y guardarlo en una variable antes de un bucle es más rápido que cargarlo en cada iteración en la comprobación de un for,
y etc.

La paciencia es una cualidad muy positiva.

Leer el resto de la entrada »

Hoy he estado avanzando en el trabajo con el generador de aplicaciones PHP/GTK de zenphp, estoy aprendiendo un montón de GTK, bueno como dos imágenes valen más que dos mil palabras, pasamos a las capturas mejor

Otra imagen del entorno inicial:

No hagais mucho caso a las capturas,son los primeros avances del diseño del configurador de modelos y parámetros del generador a partir de un XML…

La última versión del generador está en el directorio trunk/zenphp/generador/gtk del SVN de la Forja:
svn checkout https://forja.rediris.es/svn/csl2-zenphp/trunk zenphp
y recordar que se carga con una orden del tipo:
php zen_generador_gtk.php
Ahora mismo estoy desarrollando la parte en que se carga el fichero XML con todas las opciones y se interpretan en la interfaz de usuario para ser editadas, de forma que se puede utilizar el entorno gráfico para con varios clicks generar una aplicación web ( sencillamente ) compleja con conexión a la base de datos.
Hay editor para ver las bases de datos mysql, que encontré en la red y lo he adaptado al generador porque me parece muy útil.
Además he incluido un visor de objetos de PHP-GT de kksou

¿Cómo funciona?

Leer el resto de la entrada »

¿Por qué?

se puede leer en el documento de rendimiento de aplicaciones web con JavaScript para comprender, que su uso se puede ver como un cuello de botella o como una ayuda impresionante para manejar el DOM de un sitio web…

Para mejorar la eficiencia de un proyecto con mucho uso de JavaScript recomiendo usar xpages: http://xpages-es.blogspot.com/

Con éste artículo quiero proponer una pirámide real del programador de un framework, (sufrido XD ) y bueno, explicar los procesos que se llevan a cabo…

Leer el resto de la entrada »

Por fin, oh mondié!!, terminé con el Andamio de zenphp, el Scaffolding…

bueno,he creado un PDF (alojado en el directorio de documentos del proyecto) para ayudar a usarlo, creo que es bastante fácil y agradable de leer.

Continúo con la caché y, tras las optimizaciones, queda menos trabajo que realizar para finalizar el gestor de contenidos (CMS) y el generador de aplicaciones PHP/GTK.
¡Ánimo a todos!

Esta vez he tomado la captura en Windows, el primer “cartucho” o dicho de otra forma: aplicación configurable donde poder incluir nuestro propio código a generar es el de un portal en AJAX.

Se pretende hacer un portal, algo como este pero más sencillo y administrable desde una interfaz gráfica en PHP/GTK que use el sistema zenphp como framework de aplicaciones web usando el paradigma de programación orientada a aspectos.

PASOS PARA LA INSTALACIÓN DE PHP/GTK

Instalar php5, php5-dev,gtk2,gtk+
++++++++++
apt-get install php5 php5-dev libgtk2.0-0 libgtk2.0-common libgtk2.0-dev
++++++++++
Descargar PHP-GTK de :

http://gtk.php.net/download.php

concretamente he usado : http://gtk.php.net/do_download.php?download_file=php-gtk-2.0.0.tar.gz
descomprimir,configurar y compilar:
++++++++++
./buildconf ; ./configure ; make ; make install ; make test
++++++++++
Configurar /etc/php5/cli/php.ini
++++++++++
extension_dir = “/usr/lib/php5/20060613+lfs/” #en mi caso…
extension = php_gtk2.so
++++++++++

Ya tenemos PHP/GTK2.0 instalado, ¿Qué podemos hacer ahora?

Probar la demo de php Gtk:

php-gtk-2.0.0/demos$ php5 phpgtk2-demo.php

Obtenemos la siguiente ventana con los tests…

Además podemos probar la demo de aplicación generadora de aplicaciones de zenphp, que usa un fichero XML para definir el contenido del programa, como se hace con zen_POA. El esquema viene a ser el siguiente:

Para generar nuestras propias interfaces de PHP/GTK2 podemos hacerlo con Glade2:

,o un buen editor visual de interfaces como Gazpacho

sudo apt-get install gazpacho

Lo mejor del generador de aplicaciones es que es multiplataforma y genera aplicaciones para PHP/GTK o bien para web, como se pretende
es difícil llevar varias partes del Proyecto a la vez, pero con esfuerzo y dedicación se puede hacer, aunque lo más importante es la concentración en mi opinión.
Salu2!