« »
Jan 22

Una de las técnicas más usadas en el desarrollo de aplicaciones PHP es la de mezclar la lógica y el código necesarios para la presentación con la lógica de negocio de la aplicación, todo en un mismo archivo. Esto, entre otros problemas, dificulta enormemente el mantenimiento y cualquier tipo de ampliación o modificación de la aplicación.

Como solución a esta situación hace tiempo que aparecieron los sistemas de plantillas. Un sistema de plantillas tiene como objetivo principal ofrecer los mecanismos necesarios para separar por un lado la lógica de negocio y por el otro la lógica y el código necesarios para la presentación. Como consecuencia se separa el código PHP del código HTML lo que, en teoría, ofrece la posibilidad de que alguien sin conocimientos de PHP modifique la apariencia de nuestra aplicación.

Este es el objetivo que debería tener un sistema de plantillas y no, como algunos, únicamente limitarse a separar código HTML de código PHP sin ofrecer ninguna facilidad para codificar la lógica necesaria para la presentación. Existen muchos casos en los que necesitamos de cierta “lógica” para presentar los datos. Por ejemplo, si la lógica de negocio es obtener un determinado listado de BD y la lógica de presentación es mostrarlo en cuatro columnas sería incorrecto (y una tontería) hacer que la función encargada de obtener los datos de BD devolviera cuatro arrays, esa función no debería tener que preocuparse de como se presentan los datos que devuelve (forma parte del Modelo en un MVC).

Puedes intentar separar la lógica de la presentación de la presentación en si, es decir, con el ejemplo anterior sería crear una función (capa) intermedia que se encargara de separar los datos devueltos en cuatro arrays. Esto, al menos a mi modo de ver, no tiene ningún objetivo válido y son ganas de rizar el rizo, ya que ni que trabajemos con un MVC esta función que separa en cuatro arrays sigue formando parte de la Vista, sumado a que creamos un código menos óptimo y que, si te paras a pensar en un caso práctico, ¿no debería ser tarea del diseñador (plantillas) cambiar la apariencia y en lugar de listar cuatro columnas listar cinco?. A pesar de realizar esta separación dentro de la Vista existen muchos ejemplos que demuestran que es casi imposible no necesitar codificar cierta “lógica” en las plantillas (ni que sea un “if” para decidir que código se genera dependiendo del navegador). El objetivo de un sistema de plantillas como Smarty es codificar esta lógica asociada a la presentación en las plantillas ya que sino simplemente sería un sistema de sustitución de variables y no lo que es.

Después de esta breve explicación acerca de lo que es, o de lo que en mi opinión debería ser, un sistema de plantillas voy a centrarme en el caso de Smarty. Smarty cumple perfectamente los objetivos planteados a parte de ofrecer numerosas características adicionales. Personalmente empecé a usar Smarty unos tres años atrás, hasta entonces siempre había trabajado con sistemas de plantillas propios usando el PHP como lenguaje para el equivalente a las TPL separando perfectamente lógica de negocio de presentación, o muchos más años atrás con soluciones “mixtas” como trabajar con temas, algo parecido a lo que hacía el php-nuke (un poco cutre, sí, pero increíblemente cómodo y efectivo).

Aunque cuando empecé a usar Smarty no andaba muy convencido durante los tres últimos años lo he usado para casi todo en numerosos proyectos (algunos con decenas de millones de páginas vistas por mes) y como me temía, aún se han hecho más evidentes los problemas que ya detectaba desde un principio. Todos los problemas son consecuencia de lo mismo, Smarty es un sistema de plantillas basado en el procesado de archivos de tags (las TPL). Sólo aclarar que el objetivo de este post (si es que tiene alguno) no es proclamar el dejar de usar los sistemas de plantillas sino usar sistemas donde el mismo PHP sea el lenguaje de las plantillas.

Problemas comunes en los sistemas de plantillas basados en el procesado de archivos de tags (comparándolo con el uso directo del PHP):

  • Tienen un problema importante de rendimiento. No hace falta decir que con el uso de plantillas de tags estamos añadiendo un lenguaje más a procesar e interpretar desde PHP. Smarty es un sistema escrito en PHP con miles de lineas de código, pues a parte de tener que incluirlas en tu aplicación es desde el PHP que se va a interpretar este pseudo-lenguaje de las TPL. Para paliar esto Smarty compila las plantillas para no tener que parsearlas cada vez, gracias a esto es uno de los más rápidos, pero cada vez que cambies las TPL tendrá que parsearlas y se ha de tener en cuenta que el código que genera siempre será peor que el q harías tu directamente en PHP. Con la compilación Smarty reduce mucho este problema pero al disponer de tantas funcionalidades puedes llegar a hacer plantillas medianamente complejas que tardarán muchísimo a la hora de ser compiladas (en una aplicación (.com) en constante desarrollo debido a cambios drásticos en el código más de una vez es necesario borrar las plantillas compiladas manualmente para regenerarlas). Dependiendo del tipo de aplicación y número de plantillas esto puede ser muy preocupante o no: no es lo mismo una aplicación no muy dinámica que funcione con relativamente pocos tipos de pantallas (pocas plantillas distintas) como un CMS donde la mayoría de peticiones las puede atender un sistema de cache externo al PHP (Squid) y si le sumas un acelerador de código puedes llegar a trabajar bien con Smarty, que en el otro extremo, una aplicación muy dinámica (muy web 2.0 :) con participación de los usuarios, AJAX, varios RSS, etc. lo que comporta muchas plantillas distintas y poder usar comparativamente poca cache, en estos casos si que al menos has de disponer del acelerador de código sino a la que tengas mucho tráfico verás caer tu rendimiento.
  • Aunque no mucho pero dificultan el mantenimiento. En el caso de Smarty es necesario disponer de directorios para guardar las plantillas compiladas, varios archivos, TPL, probablemente archivos de configuración, y como no el Smarty en si (instalarlo, mantenerse actualizado, posibles bugs, etc.). En el caso de Smarty es necesario disponer de distintos directorios para compilación y cache para plantillas con el mismo nombre, si a esto le añades q para mantener un poco de orden y poder cómodamente administrar (y desarrollar) los distintos módulos de una aplicación has de ir creando directorios, puedes acabar con un número considerable de directorios para cache y compilación. (por cierto, varios programadores trabajando con las mismas TPL necesitarán de directorios compile_dir individuales para ver lo que están haciendo y no lo del vecino).
  • Es necesario aprender un nuevo pseudo-lenguaje de programación… Algún problema, no, pero es un fastidio tener que ir constantemente a ver como narices consigues hacer algo con Smarty que con PHP es trivial y más óptimo. En el caso de Smarty puedes llamar al PHP y solucionado claro, pero entonces… maldita la gracia, son ganas de mandar de ruta turística al intérprete de PHP por miles de lineas de código para acabar haciendo lo que podía hacer desde un principio.
  • En mi opinión, dificultan bastante el desarrollo. A parte de tener que aprender un nuevo lenguaje como siempre añadir una capa más de librerías de una tercera parte introduce problemas. En varias ocasiones en el desarrollo aparecen “fatal errors” dentro de las librerías Smarty (no en tu código) provocados por un fallo en tus plantillas o en los datos que reciben… (cojonudo!). Otro fallo frecuente es con una plantilla que ya está compilada cambiar el código PHP que la genera agregando o quitando funcionalidades usadas en la plantilla pero sin tocar para nada la plantilla… en este caso te puede llegar a aparecer un “fatal error” indicando la línea dentro de la plantilla compilada (q tampoco es tu código)… muy práctico también :|
  • No es garantía de que se cumpla el objetivo de un sistema de plantillas, imprescindible si trabajamos con MVC. Como exponía anteriormente, una de las consecuencias de necesitar de cierta lógica en las plantillas es que los sistemas como Smarty proporcionan estructuras de control (“if”, “foreach”), funciones, variables, operadores, etc. pudiendo hacer casi todo lo que puedes hacer con el mismo PHP, con lo que pasa a ser responsabilidad del programador no codificar lógica de negocio en las plantillas ya que poder, puede.
  • No es tan fácil de usar para un diseñador. No cumple el objetivo de que un diseñador sin conocimientos de programación (en PHP) pueda llegar a realizar el mantenimiento de la presentación de un site modificando las plantillas. Si a la lógica de presentación existente en las TPL (algunos “if”, “foreach”, etc.) le sumas que la gracia de usar Smarty es usar su potencial (generación de forms a base funciones, modificadores de texto, plugins propios, y un largo etc.) resultan unas TPL inteligibles para alguien que no sea programador (de PHP o de lo que sea, pero programador). En su Why Use Smarty venden como una de sus características destacables que un diseñador sin conocimientos de programación PHP puede fácilmente aprender Smarty porque son tags muy fáciles de usar, ¿realmente creéis que es mucho más fácil de entender {$foo} que <?=$foo;?> o {if –} que <?if –?> para un diseñador?…. deben haber realizado un estudio científico con un grupo de diseñadores para afirmar esto ¿no? Si quieres que un diseñador sin conocimientos de programación llegue a modificar las TPL del Smarty (con el Dreamweaver en “Modo Diseño”) de un site medianamente complejo te ves obligado a usar Smarty casi como un sistema simple de sustitución de variables.

Con el último punto sólo aclarar q en absoluto pretendo faltar a los diseñadores. Simplemente expongo que ni de coña Smarty es la solución mágica, seguro que unos cuantos de los que lean esto han tenido que justificar a alguien porque no dejas que los diseñadores editen las plantillas a la brava con Dreamweaver…. Sólo un apunte acerca de la diferencia (al menos para mi) entre “programador web” (a veces mal llamado diseñador), llámese a aquel diseñador web medio o avanzado con conocimientos de programación web: JavaScript, AJAX, XHTML, CSS, Smarty (si no lo sabe lo aprende en un plisplas, pero idem con el PHP), etc. del “diseñador” con conocimientos de diseño avanzado, con estilo, mucho photoshop, flash, mucha creatividad ,etc. pero sin programación. Lo que planteo es que el aprendizaje de Smarty es igual de fácil o difícil que el de PHP para ambos perfiles.

Es cierto que todo lo comentado son problemas “menores” dependiendo de tus recursos (dinero y tiempo). Invirtiendo más dinero en hardware y más tiempo en desarrollo y mantenimiento puedes usar Smarty con toda tranquilidad. Siempre que saber que te estás gastando más dinero y que tardarás más en los desarrollos te inspire tranquilidad. En muchas ocasiones el uso de Smarty es ocasionado por dejarse impresionar por la cantidad de cosas que puedes hacer con él: cache, plugins, transformaciones de datos, forms, filtros, etc. Pero al igual que lo que comentaba acerca de la elección de ADOdb como layer de abstracción de base de datos, es importante valorar lo que vas a usar de todo lo que ofrece, y sobretodo tener en cuenta el coste en rendimiento y tiempo de desarrollo que va a suponer.

En resumen, usar un sistema de plantillas es una buena práctica y si te dispones a desarrollar una aplicación con poco tráfico (como un dashboard de uso no público o una intranet) o dispones de dinero suficiente para hacer una buena inversión y necesitas de sus características, con tiempo y ganas, Smarty es uno de los mejores y más potentes. Pero has de tener en cuenta que si no necesitas de todo lo que ofrece y sólo quieres poder cumplir el objetivo de separar la lógica de negocio de la presentación con un sistema propio usando PHP lo puedes conseguir muy eficazmente. A mi personalmente el uso de Smarty no me compensa y después de tres años viviendo juntos hemos roto, a pesar de que todavía arrastro proyectos enormes q lo usan con todo lo nuevo q hago desde hace unos meses uso (o he vuelto a usar) un sistema de NO plantillas propio usando el mismo PHP con el añadido de un sistema de cache de objetos genérico (con él no sólo cacheo páginas HTML, sino también resultados de queries, de cálculos, etc.). Lo de “NO plantillas” viene a cuento de usar el mismo PHP para las plantillas en lugar de un lenguaje específico.

Lo que explicó y la solución que planteo no es nada nuevo… precisamente para mi y para muchos proponer el uso de un template engine basado en PHP es retomar algo “viejo”. En un siguiente post propondré un template engine basado en PHP que simula al Smarty para así poder migrar código más fácilmente, pero para a quien esto le venga de nuevo y para no dejarlo colgado explicó brevemente de que se trata (aunque siempre puedes googlear un poco).

Muy brevemente, la solución: En lugar de inicializar Smarty e ir haciendo assign() de todo lo que le quieres pasar a la plantilla vas almacenando esta información en un array (u objeto), finalmente en lugar de llamar al display() del objeto Smarty haces un include() de la plantilla escrita en PHP. Las plantillas PHP son básicamente archivos HTML que llevan incrustado PHP para sacar por pantalla los datos almacenados anteriormente y con algunos “if” y “foreach” para codificar la lógica de la presentación (puedes usar short_open_tag (<? y <?=) para hacerlas más amigables para los diseñadores :)

Un pingback obligado hacia este post de Ricardo Galli explicando su opinión al respecto y el mal rendimiento de Pligg, un intento de meneame.net usando Smarty.

Be Sociable, Share!
Tagged with:

15 Responses to “Sistema de NO plantillas con PHP5 para un MVC (aka Problemas con Smarty)”

  1. meneame.net says:

    Sistema de NO plantillas con PHP5 para un MVC (aka Problemas con Smarty)…

    Artículo que describe unas cuantas verdades acerca de los sistemas de plantillas que usan el procesado de archivos de tags (concretamente Smarty). Explica el mal rendimiento, difícil desarrollo, etc. comparado con un sistema de plantillas que use al …

  2. Rodolfo Ugalde says:

    Exelente articulo!!!!!

    Me respondio muchas dudas sobre Smarty. y estare al pendiente de tus articulos.
    Saludos desde Tx.,Queretaro, MX -.-

  3. Andres RJ says:

    MUY BUENO EL ARTICULO

  4. Luis Abarca says:

    Muy bueno, ese sistema de plantillas sin plantillas se me hace la mejor opcion, es lo que uso actualmente

  5. Josep Maria Sala says:

    Estoy totalmente de acuerdo, no solo en que supone una nueva capa de dificultad para los diseñadores, sino tambien en el rendimiento y optimización de codigo. Symfony ya se ha librado de los template engines y me encanta el funcionamiento (aunque como converso a Ruby on Rails, en este punto no soy nada neutral).

  6. Muy bueno el artículo, muy enriquecedor, sería muy bueno ver un ejemplo, sería la frutilla de la torta, muchas gracias y éxitos.

  7. alex marenco says:

    las plantillas son una maravilla y ayudan mucho pero siempre en el contexto indicado, por ejemplo yo uso vtiger crm y este trabaja smarty y se entiende a la perfeccion

  8. Javor says:

    Un poco tarde, pero quisiera hacer un comentario, como desarrollador de aplicaciones web.

    Cuando externalizas el diseño te encuentras con problemas a la hora de coordinar tus scripts en PHP y la presentación.

    A mi me ha costado un poco, pero al final he conseguido que la empresa diseño aprenda Smarty. De hecho se que ahora lo están utilizando en otros programas.

    Obviamente un diseñador no nace sabiendo Smarty, pero con un poco de esfuerzo por su parte es mas fácil manejarse con ello y me permite a mí, el desarrollador, controlar el acceso a los datos por parte del diseñador.

    Eso si, hay que suministrar al diseñador una documentación en la que se le especifique la información de la que dispone. Una documentación de interfase.

    Pero cuando consigues entrenar a los diseñadores se trabaja de maravilla.

  9. Javor says:

    Me he dejado algo en el tintero.

    Lo peor de Smarty, el error reporting. Los errores pueden ser muy difíciles de encontrar y eso me obliga a ponerme a mirar syslog y demás para decirle al diseñador por que la pantalla se ha quedado en blanco.

    Espero que lo mejoren.

  10. Jep Aribau says:

    Savant es un sitema de plantillas sin compilar y que usa la sintaxis de PHP para la lógica del template. Viene a ser un sustituto del include().

  11. Normalmente los diseñadores, sólo diseñan o los que maquetan no tienen buen nivel de css, etc. Es aún que pienso que las plantillas estan más enfocadas a lo
    s programadores para que el código sea mas limpio, php y html separado.

  12. Paolo says:

    Buen artículo,

    En general estoy de acuerdo contigo. No siempre un producto en específico es la solución para todos los casos. Por esto, me parece justo indicar que hay algunos casos en los que resulta mejor el uso de Smarty que el de un sistema de plantillas directamente trabajado en PHP.
    Particularmente, el caso que me parece más obvio es el de una página en varios idiomas. En este caso, la capacidad de uso de los confs de Smarty es bastante agradable.
    Igualmente, hay ocasiones en las que la lógica de la capa presentación es compleja y puedes utilizar la etapa de compilación de Smarty para que de un sólo TPL puedas crear varias versiones compiladas distintas… cada una optimizada para su objetivo.
    Finalmente, con respecto al rendimiento… efectivamente no tener que cargar nada adicional siempre será más rápido que tener que hacerlo, sin embargo, con el “tunning” apropiado se puede hacer que el Smarty tenga un comportamiento excelente y que el código compilado sea bastante más legible.

    Si me permites la publicidad, estoy escribiendo en mi blog precisamente un conjunto de artículos sobre la optimización de Smarty para que su desempeño sea mucho mejor… trabajo en un sitio que sirve unas 120 millones de páginas totalmente dinámicas al mes y uso Smarty con muy buenos resultados.
    La dirección de estos artículos (por si a alguien le interesa) es:
    http://pragone.com/tag/smarty

    En cualquier caso, muy buen artículo. Enhorabuena!

  13. gaston says:

    como desarrollador web, creo que no presenta incovenientes mayores y complejos o dificiles de superar, en cuanto a un diseñador, solo se debe ocupar de las plantillas o maquetas html y el resto lo agrega un desarrollador, no estoy de acuerdo con este articulo, pero son opiniones variadas y tambien validas segun la experiencia de cada uno, yo uso mucho smarty y no me parece un mal producto, el “pseudo-codigo smarty” si uno sabe desarrollar no es tan complejo y tampoco tan dificil, de hecho en la pag de smarty se cuenta con ayuda y es muy completa y contiene ejemplos para todo, esta en varios idiomas lo cual no creo que eso sea un incoveniente tampoco, de cualquier manera el otro camino seria desarrollar un framework para vistas propio, cuando alguno haga algo mejor enviemelo y con gusto lo utilizare….

    saludos

  14. Me gusta el modelo smarty tiene enfoque administrativo, lo uso para proyectos de bajo trafico. Soluciona el problema de apartar el diseño artistico del trabajo tecnico. Soluciona las debilidades del diseñador y del programador para sumar juntos sus talentos y dar lo mejor de lo mejor. La idea es brillante. Me encanta la idea de programar sin preocuparme por el diseño.No es tan perfecto como el uso directo de PHP cuya comparacion no tiene objeto pero es un toys muy bonito para usar.

  15. Diego says:

    Estoy de acuerdo contigo. A mí no me gustan los sistemas de plantillas en PHP porque introducen nueva sintaxis que te tienes que aprender y además son lentos porque es otro proceso adicional que puede hacer el PHP.

    Pero mi compañero es que lo defiende, incluso se está haciendo el suyo propio como recuerdo del antiguo PHPLib. Creo que es trabajo inútil porque, además, no lo va a dotar de lógica, símplemente es un sustituidor de variables. Y eso no es un gestor de plantillas.

    Yo creo que un sistema de plantillas, teniendo al PHP, que para eso (y otras cosas) se inventó, es una tontería. Sobra. Quizás no sea muy elegante, pero es mucho más rápido de desarrollar, mucho más fácil de mantener y cuando se produce un error sabes donde está.

    Luego, si quieres mejorar el rendimiento, hazte un sistema de caché (o usa uno hecho, o usa uno de HTTP Proxy) y también un acelerador como XCache o eAccelerator.

    Además, la claridad del código no depende ni del lenguaje ni del sistema de plantillas, depende del programador. Por lo tanto la claridad y mantenibilidad del código no se puede dejar de la mano del sistema.

    Nosotros nos estamos construyendo nuestro propio framework MVC (para nuestra intranet y quizás para otros proyectos) y nuestra principal premisa es la simplicidad (seguimos la metodología KISS) y un sistema de plantillas no es exactamente algo que sea simple, tanto interna como externamente.

    Ahora a ver si convenzo a mis compañeros que, como dije antes, están con el antiguo PHPLib y de ahí no hay quién los saque.

Leave a Reply

preload preload preload