estrategias para implementar un motor de plantillas Espero generar aquí una buena discusión de la que todos aprendamos algo. Llevo unos días haciendo un experimento[1] para implementar un motor de plantillas a partir de un intérprete SAX de XML. (Que quede claro, que sólo es un proyecto personal, no pretendo hacerle sombra a otros motores).
Y así poder generar la vista de un pequeño CMS basado en la arquitectura Modelo-Vista-Controlador, de la cual se ha hablado en otro hilo.
Bien, después de tener algo más de 100 líneas de código, he decidido que el experimento ya ha concluido y es hora de implementarlo como dios manda.
Según he investigado en otros foros[2] se puede utilizar o bien un intérprete SAX, o la extensión PHPDOM o implementar una máquina de estados[3] para procesar un archivo HTML con etiquetas especiales que representen la (poca) lógica de cada plantilla. (Digo poca, porque la idea NO es crear un lenguaje nuevo, sólo separar la lógica del negocio de la persentación, además, tampoco es necesario sobrecargarla)
Personalmente implementar una máquina de estados me parece un poco bestia, aunque en los foros de sitepoint[3] dara buenos resultados en cuanto a rendimiento sobre todo.
Usar PHPDOM sería ideal, pero no me gusta nada que sea una extensión experimental, así que yo por lo menos descarto su uso.
Tragándome código de otros motores de plantillas, veo que hacen mucho uso de expresiones regulares para localizar bloques, variables,... un enfoque que todavía no me queda claro para el modelo de plantillas que uso (más abajo hay un ejemplo de plantilla, no obstante en mi página[1] hay ejemplos).
Una muy interesante, que Harry Fuecks hizo con SimpleT [4], como PHP en sí mismo es un motor de plantillas, utilizarlo como tal, pero teniendo en mente la separación de lógica del negocio, modelo de datos y presentación. Interesante sí, pero yo me he "emperrado" en usar un lenguaje para las pantilllas basado en XML. :)
Y por último usar un intérprete SAX, como hago actualmente, lo que se me plantean problemas para organizar bien el código o diseñar bien la aplicación. Además, ¿hasta qué punto es eficiente usar un SAX "parser"?
A parte que el intérprete ignora los comentarios y las declaraciones DOCTYPE, un fallo feo y peludo.
cómo solucionar eso?¿Qué estrategía seguiríais? ¿Cómo?
Siendo este el modelo de una plantilla bastante simple:
Código:
Y correspondiéndole el siguiente código en PHP:<html>
<head><title>${titulo}</title></head>
<body>
<list name="amiguetes" as="amiguete">
<a href="${amiguete.url}">${amiguete.nombre}</a><br/>
</list>
</body>
</html>
Código PHP:
$view =& new Template('plantilla.html');
$view -> expose('titulo', 'PHPMarker Test');
$lista[0] = array( 'url' => '...', 'nombre' => 'pepito');
...//añadimos más registros a la lista
...
$view -> expose('amiguetes', $lista );
$view -> process(); //muestra la plantilla
Sabiendo esto último, había pensado delegar el trabajo de cada etiqueta especial -al estilo de las Custom Tags de las JavaServerPages pero no tan complejas- (porque habrá alguna etiqueta más como transformaciones de texto y un bloque condicional) en clases para así conseguir una aplicación flexible, que no sea extremadamente complicado y engorroso añadirle funcionalidad y mantener en otra clase el modelo de cada plantilla (las listas y variables que se añaden con el expose() ). Pero teniendo en cuenta la naturaleza de PHP (es intepretado), no me parece buena idea tener muchas clases/archivos implicados en generar una sola página. (no es lógico no?) Así que en cuanto a "repartir el trabajo" no sé cómo hacerlo.
Entonces, cómo lo vemos señores? Qué ideas tenéis? Qué os parece lo que os planteo?
Siento el pedazo ladrillo que he escrito al final, espero impaciente nuevos puntos de vista :D
Aquí los links:
[1] http://people.javahispano.org/vitxo/phpmarker/
[2] http://www.sitepointforums.com/forum...hp?forumid=147
[3] http://www.sitepointforums.com/showt...ighlight=state
[4] http://simplet.sf.net/
) no pude más que aplaudir. 
porque interpretar sólo cuando sea necesario es importante.
Este tema le ha gustado a 1 personas