Surforce-base: primera versión con Zend_Layout

Hacer un rato actualicé el repositorio svn del proyecto surforce-base con la inclusión del manejo de "layout" (diseño) provista por Zend_Layout. Anteriormente teníamos que en cada vista de todos los módulos de nuestro sistema incluir indefectiblemente el código para el cabezal en la parte superior y el pié en la parte inferior.

Algo así:

1  
<?php echo $this->render('header.phtml'); ?>
2  <?php 
echo $this->render('menu.phtml'); ?>
3  

4  <div id="noticias">
5  
6     Hola, son el index de Noticias, 
7     si quieres ingresar al admin debes ir a 
8     <a href="<?php echo $this->baseUrl ?>
9  
      /noticias/admin/">Admin</a>
10  </div>
11  
12  <?php echo $this->render('footer.phtml'); ?>



De ahora en más, simplemente hay que poner el contenido de la vista sin los renders de "header" ni "footer".

El detalle más importante de todo esto es que en el modelo anterior, si tuviéramos que cambiar la estructura base del sitio -por ejemplo- cambiar de lugar el cabezal, el pie, o agregar un menú, o cambiarlo de lado, hay que modificar todas las vistas para hacerlo.

De esta nueva forma todo el esqueleto del sitio se encuentra en el layout.phtml, ubicado al mismo nivel que el código del cabezal y el pie (/html/scripts) y contendrá el siguiente código:


1  
<?php echo $this->render('header.phtml'); ?>
2  <?php 
echo $this->render('menu.phtml'); ?>
3  

4  <?php echo $this->layout()->content?>
5  

6  <?php echo $this->render('footer.phtml'); ?>



Y lo único que hubo que agregar fue en el bootstrap (index.php) algo como esto:

1  
<?php
2  
3  
/**
4   * Zend_Layout
5   */
6  
define('APP_PATH'realpath('.'));
7  
8  
Zend_Layout::startMvc(array(
9      
'layoutPath' => APP_PATH '/html/scripts'
10  
));
11  
12  
$view Zend_Layout::getMvcInstance()->getView();
13  
?> 
14  



Y listo, luego hay que sacar en todos los módulos las referencias al cabezal y pie para que este no se repita, ya que quedó definido en el "layout".

Más información en el proyecto en el cual pueden bajar sus fuentes y probarlo, y hasta ver las diferencias consultando el log del SVN.

Fuente: Introduction to Zend_Layout (updated for ZF 1.5!)

Actualización (24/04/2008):

PHP&Beers Buenos Aires

Me avisan que este jueves se va a realizar en Palermo (Argentina) la primer "PHP&Beers" con el fin de juntarse desarrolladores y conocerse.

La dirección exacta es:

"Cervecería Antares (Armenia 1447, Palermo), el Jueves 24 de Abril, a las 19:30 horas."


¿Para cuando una PHP&Beers en Uruguay? ;-)

PD: nosotros hicimos una, pero fue con alumnos de mi curso de PHP5 de ORT, que luego quedamos que deberíamos hacer una regular para todos los desarrolladores PHP en general (algo que todavía no se dio).

Zend: "¡¿donde está mi helper?! ¡¿cómo lo llamo?!"

Estuve un rato teniendo problemas con un helper que había creado y que lo colocaba en el -supuesto- lugar que debía estar y la vista que lo usaba no lo encontraba.

Nota: aviso, "todo", está en el manual, lamentablemente (así que hay que leerlo ;-) )

En la sección sobre "Zend_View", en particular el punto "42.1.4. Utility Accessors", fue bastante revelador, ya que nos da las herramientas para comprender cómo el sistema registra los nombres y las ubicaciones de los helpers y poder revisar si estamos cometiendo algún error de sintaxis o de conceptos.

Aquí algunos métodos que podemos usar desde una vista:

  • getScriptPath($script): nos retorna el camino a partir del nombre de un scripts

  • getScriptPaths(): nos retorna todos los caminos de los scripts registrados.

  • getHelperPath($helper): el camino de un helper dado a partir del nombre de la clase

  • getHelperPaths(): todas las rutas registradas para los helpers


Estos métodos nos permiten hacer un "debug" de nuestro sistema y ver donde nuestro MVC encuentra o debería encontrar los helpers, muy útil para controlar que estemos haciendo las cosas bien.

Estando dentro de la vista podemos hacer

1  
<?php 
2  
3  var_dump
(  $this->getHelperPaths() );
4  
5  
?> 
6  



Y nos tira la lista de rutas que tiene definido para buscar los helpers

1  
<?php 
2  
3  
array(4) {
4    [
0]=>
5    array(
2) {
6      [
"prefix"]=>
7      
string(7"Helper_"
8      
["dir"]=>
9  
10      
string(32".\library\Zsurforce\View\Helper\"
11    }
12    [1]=>
13    array(2) {
14      ["
prefix"]=>
15      string(8) "
_Helper_"
16      ["
dir"]=>
17      string(15) "
.htmlhelpers"
18  
19    }
20    [2]=>
21    array(2) {
22      ["
prefix"]=>
23      string(25) "
Estadisticas_View_Helper_"
24      ["
dir"]=>
25      string(41) "
.application\estadisticas\views\helpers"
26  
27    }
28    [3]=>
29    array(2) {
30      ["
prefix"]=>
31      string(17) "
Zend_View_Helper_"
32      ["
dir"]=>
33      string(57) "
C:\xampp\htdocs\admin\library\Zend\View\Helper"
34  
35    }
36  }
37  
38  ?> 



Varias deducciones interesantes:

  • Que está por defecto buscando en "html\helpers" (algo que no sabía)

  • Que no hace falta decirle dentro de la vista correspondiente donde buscar sus helpers, ya que lo hace solo: \application\estadisticas\views\helpers\ (yo estoy probando dentro de la vista del módulo estadísticas)

  • No veo la ruta hacia los helpers de surforce-library

Tomando en cuenta esto último, agregué en el init del controller genérico de surforce-library:

1  
<?php
2  $this
->view->addHelperPath('./library/Zsurforce/View/Helper/'
'Helper');
3  
?>



Si volvemos a ejecutar la vista, ahora nos dice:

1  
<?php 
2  
3  
array(4) {
4    [
0]=>
5    array(
2) {
6      [
"prefix"]=>
7      
string(7"Helper_"
8      
["dir"]=>
9  
10      
string(32".\library\Zsurforce\View\Helper\"
11    }
12    [1]=>
13    array(2) {
14      ["
prefix"]=>
15      string(8) "
_Helper_"
16      ["
dir"]=>
17      string(15) "
.htmlhelpers"
18  
19    }
20    [2]=>
21    array(2) {
22      ["
prefix"]=>
23      string(25) "
Estadisticas_View_Helper_"
24      ["
dir"]=>
25      string(41) "
.application\estadisticas\views\helpers"
26  
27    }
28    [3]=>
29    array(2) {
30      ["
prefix"]=>
31      string(17) "
Zend_View_Helper_"
32      ["
dir"]=>
33      string(57) "
C:\xampp\htdocs\admin\library\Zend\View\Helper"
34  
35    }
36  }
37  ?> 




Ya aparece la ruta hacia los helpers de surforce-library.

Otra cosa interesante, que ya me permitió corregir varios problemas al definir los helpers fue el nombre de los mismos con la ruta para encontrarlos. En algunos casos había creado una clase Helper con solo el nombre de la clase y en otra con el nombre con la ruta completa para ubicarlos, pero en varios estaban mal. Si vemos el array, uno de los elementos es "prefix" y justamente, es el nombre "prefijo" que debería tener la clase de nuestro helper ;-)

Por ejemplo, si nuestro helper está en el módulo estadísticas, debemos llamarlo:

class Estadisticas_View_Helper_GoogleChart

Pero si está en surforce library solo "Helper"

class Helper_GoogleChart

¿Interesante dato, no?

Nota: al final cambié el nombre del prefijo de solo "Helper" al que debería corresponder de acuerdo a la ubicación dentro de la estructura de directorios de Zend, así que la clase pasaría a llamarse Zsurforce_View_Helper_GoogleChart.

Esta es la línea que lo define en el init() del controller:

1  
<?php 
2  
3  $this
->view->addHelperPath('./library/Zsurforce/View/Helper/'
'Zsurforce_View_Helper');
4  
5  
?> 



Por último, estaba probando el método "getHelperPath" que nos dice donde está ubicado el helper que consultamos, y en todos los casos anteriores no daba información, pero cuando arreglé las rutas, ya devolvía la información correcta.

1  
<?php
2  
echo $this->getHelperPath('googleChart');
3  
?> 



Creo que con esta explicación ahora queda un poco más claro cómo encontrarlos. ;-)

Gráficas a través de Google Chart API

Hace poco empecé a probar la API de Google Chart, un nuevo servicio web disponible que nos permite a través de una url y una serie de parámetros obtener -sin instalar nada- un gráfico que puede ser embebido en nuestro sitio web.

Lo estoy usando para desarrollos internos, y la verdad que simplifica bastante el trabajo al evitar muchos problemas, desde instalar herramientas, librerías, configuración, curva de aprendizaje, etc.

Ejecutar las primeras pruebas que aparecen en la documentación puede dar la impresión que todo es muy sencillo, pero cuando queremos obtener algo que se ajuste exactamente a nuestras necesidades es casi seguro que pasaremos algunas horas de "prueba y error" hasta lograr entener todos los parámetros y cómo cambian de acuerdo al tipo de gráfico.

Es un servicio gratuito y no tiene límites, aunque hay que avisar en caso de superar los "250,000 API calls per day".

Aquí un ejemplo de una url donde simplemente hay que pasar parámetros con los valores necesarios. Esta misma url la podemos agregar dentro de un <IMG> y como el resultado es una imágen .PNG, automáticamente la podemos tener embebida en nuestro sitio:




Lo bueno es que también puedo de forma muy simple enviar el link por mail a un usuario a partir de la url generada con los datos de mi sistema.

Aquí les dejo un ejemplo:

1  
<?php
2  
3  
foreach( $this->ventas as $venta ){
4     
$dia[] = $venta['dia'];
5     
$cant[] = $venta['cantidad'];
6  }
7  
8  
$chx implode"|"$dia );
9  
$chd implode","$cant );
10  
11  
$pars = array(
12     
"http://chart.apis.google.com/chart?chs=1000x300",
13     
"cht=ls",
14     
"chxt=x,y",
15     
"chds=1,100",
16     
"chxl=0:|" $chx "|1:|0|50mil|100mil|150mil|200mil",
17     
"chtt=Ventas por Dia",
18     
"chd=t:" $chd,
19     
"chm=D,C6D9FD,1,0,8|D,4D89F9,0,0,4",
20     
"chg=20,50,1,0"
21  
);
22  
23  
$url implode"&"$pars );
24  
25  
?>
26  
<table border=1 align="center">
27   <tr>
28    <td>
29     <img src="<?php echo $url ?>" alt="Ventas por Dia"/>
30    </td>
31   </tr>
32  </table>
33  
34  



Tal vez no sea lo mejor para todos los contextos, pero lo bueno es que usamos una herramienta de Google que está probada y tiene un respaldo de calidad detrás, como así también nos libera de tener que instalar librerías en nuestro servidor, ancho de banda y tiempo de procesador para generar los gráficos.

Por el momento me está siendo muy útil ;-)

Artículo recomendado: "Modelando con ArgoUML aplicaciones en PHP"

El otro día llegué por accidente a este artículo donde el autor nos explica cómo funciona ArgoUML: una herramienta libre que nos permite diseñar diagramas UML y que a su vez podemos tranformarlos a código PHP (entre otros lenguajes).

Al final del artículo comentan, algo que también vi y que es lo único que no me terminó de convencer, es que el código generado es bastante "sobrecargado" en el sentido que agrega líneas que sirven solo para la herramienta Argo, por lo cual no nos aportan nada a la hora de desarrollar.

De todas formas, es una buena herramienta para hacer diagramas (la he usado en mis clases de PHP5) y una opción cuando queremos generar código automático. Tal vez se podría investigar cuan complejo es modificar el módulo de PHP para que el código sea un poco más "limpio".

Entradas populares