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.

saludos

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!

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.

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.