Por qué no me gustan las plantillas T4

A mi anterior entrada la titulé “Las plantillas T4 son basura” cosa que respondió más a mi estado de bronca contra éstas que a su verdadero valor como herramienta. Muchos me preguntaron sobre el por qué de tal calificación y la verdad es que ese por qué es demasiado largo de explicar pero voy a mostrar la punta del ovillo para que a quien le interese pueda descubrirlo por sí solo.

Veamos un par de ejemplo muy sencillos, el primero es crear un CVS partir de una array definido como sigue:

image

Lo que queremos obtener es lo siguiente:

image

T4

StringTemplate

image image

Ambos dan por resultado exactamente la misma salida. Ahora, como no soy experto en ninguno de los dos, doy por seguro que existen mejores maneras de hacerlo tanto usando T4 como StringTemplate. Pero, si damos por válido el ejemplo, podemos ver claramente la diferencia en legibilidad y, aunque el ejemplo es muy pequeños, en mantenibilidad la diferencia también es evidente.

Pero veamos algo levemente más complejo, solo un poquito más complejo, generemos una tabla html para ver algunas diferencias. Aunque con StringTemplate lo haría así:

image

Voy a refactorizarla y compararla en la tabla de abajo.

T4

StringTemplate

image image

Nuevamente aquí estoy seguro de que existen mejores maneras de hacerlo tanto con T4 como con StringTemplate pero bueno, que valga el ejemplo. así que veamos… (suspiro prolongado) por donde empezar….?. quizás deba aclarar que mientras que la plantilla de la derecha está completa, a la de la izquierda  le quité varios renglones con directivas varias del tipo <@template> y <@output>. 

Antes de comenzar pregunto: ¿soy yo, o en la plantilla del lado izquierdo hay mucho amarillito?

Bueno, ahora si, lo primero es que dado que en la plantilla de la izquierda tenemos código, este puede explotar con alguna exception. Por ejemplo, que sucede si data es NULL? Sí, tendremos una bonita exception y entonces quizás debamos depurar la plantilla. Sí, leíste bien: depurar una plantilla! por más ridículo que suene, es algo que probablemente debamos hacer. En cambio, con la plantilla de la derecha obtendremos simplemente una tabla html vacía, no muy útil pero válida al fin.

Otro punto es que cualquiera que haya usado T4 ha sufrido alguna vez la pérdida de alguna etiqueta de apertura o cierre y ha perdido la vista tratando de encontrar donde es que le falta abrir o cerrar un tag. Y es que en semejante sopa de tags cualquiera se pierde. Por eso es común ver comentarios en la plantilla al estilo: // cierra foreach ya que uno termina preguntándose ¿que es lo que está cerrando esta llave? Bueno, esa llave está cerrando un foreach!

En cuanto a la calidad de la salida solo puedo decir que con la plantilla de la derecha, sin ningún esfuerzo adicional, obtengo un html perfectamente tabulado mientras que con la de la derecha….uhmmm, bueno… requiere algún trabajito adicional que se resuelve agregando más código.

Tal vez algo que me agrada de StringTemplate es que nos mantiene protegidos de sus mecanismos internos, es decir, uno no está obligado, y de hecho no debería estarlo, a entender cómo es que funciona internamente. Pero T4 si nos obliga, solo basta ver los distintos tipos de bloques que existen para darse cuenta: ¿Standard feature block?, ¿Class feature block? Además deben ir en un orden específico o no compilan. Sí, esas son las tuberías saliéndose hacia afuera a las que me refiero, el creador debe estar consciente de a dónde va a ir a parar lo que pone en cada block según el tipo de bloque, debe entender o imaginar como es la clase que T4 genera por detrás. Por tal motivo, T4 es solo para programadores.

Corto acá pero antes debo aclarar que no basta solo con “ver” las diferencias sino con “entender” las diferencias, entender todo lo conceptual que hay por detrás de la elegancia de StringTemplate (o de la inelegancia de T4).

Sin categoría

8 thoughts on “Por qué no me gustan las plantillas T4

  1. Ahora si veo con «fundamento» que tienes algo de razón al respecto… sirve, como excusa ante quien sea, que no es lo mismo el T4 (que se supone una mejora) respecto al stringtemplate y que su «cambio» supone mas , un paso atras y mas tiempo de dedicación, cuando, al estar en un proyecto por años, tienden a quitarnos un «porcentaje» de nuestro tiempo de desarrollo porque se supone, que cada vez somos «mejores» en lo nuestro…

  2. Buenas. La verdad es que si lo piensas el engine de proceso de T4 es el engine de de web forms remodelado, algo que a microsoft le funcionaba y no dedicaron demasiados recursos en adaptarlo para la creacion de plantillas.

    Viendo la potencia de razor para la creacion de web forms, no seria de extrañar que en un futuro remodelaran T4 para usar razor, de seguro que hay algun proyecto en este sentido y entonces si, la potencia de T4 usando razor seria comparable a stringTemplate.

  3. Técnicamente usar Razor como generador de plantillas ya es posible hoy día.
    Cierto, no está integrado, requiere un poco de código, alguna «chapuza» y demás, pero es que realmente Razor es un simple generador de plantillas! 😀

    La «chapuza» la teneis en: http://thegsharp.wordpress.com/2010/07/07/using-razor-from-a-console-application/

    Así que @Vicente, la verdad es que coincido contigo. Espero (en los dos sentidos de la palabra) ver plantillas T4 basadas en Razor 🙂

  4. @NombreRequerido, no he podido entender lo que dices en tu comentario, solo que tengo «algo de razón».

    @Vicente, creo que Razor tiene una sintaxis y algunos conceptos superadores a los de Web Forms y T4 pero sigue siendo más de lo mismo: una sopa de bloques de código entremezclados con bloques de plantilla. La legibilidad es superior y lo mismo aplica a la mantenibilidad pero sigue estando un poco lejos de StringTemplate.

    @Eduard, buen aporte el que haces, gracias. Yo la verdad es que espero ver menos plantillas T4 porque hay tantas otras opciones superiores que habría que justificar muy bién el por qué las usamos.

  5. Creo que en ciertos aspectos tienes parte de razón en tus comentarios, pero no deja de ser un análisis imparcial de alguien que proviene de StringTemplate y no se siente cómodo con el cambio de tecnología. Esto, en cierto modo, es bastante normal, nos sucede a muchos.

    Creo que como conclusión de tu post se podría extraer que T4 es una tecnología mucho más potente e integrada con otras herramientas de desarrollo (como Visual Studio), pero debido a esa potencia y elevado grado de flexibilidad, es necesario incluir más «ceremonia» en tus plantillas para expresar la misma «esencia».

    Algunos aspectos en los que T4 es netamente superior a StringTemplate: Potencia expresiva y flexibilidad (como desventaja de esto, también más «verbosidad» que StringTemplate); Integración con Visual Studio en cuanto a la capacidad de depurar plantillas siguiendo el dataflow que las origina; Servicios del lenguaje para plantillas de T4 en Visual Studio: Coloreado de sintaxis, IntelliSense, capacidad para el uso de variables tipadas y, en general, de todo el sistema de tipos de .Net, mayor eficiencia en la gestión de memoria en tiempo de generación (Garbage Collector, etc.).

    Creo que si tu mayor queja es el exceso de verbosidad en las plantillas de T4, y dado tu profundo dominio de StringTemplate (supuestamente) y la necesidad de generar plantillas T4 en tus ultimos proyectos, quiza deberias haber invertido algo de esfuerzo (tampoco requiere demasiado puesto que la sintaxis de T4 es bastante estricta) en crear un traductor de plantillas de StringTemplate a plantillas de T4… De ese modo podrias seguir usando StringTemplate como tecnologia para crear tus plantillas, para posteriormente traducirlas a T4 y emplearlas en tu proyecto en cuestión… Te lo dejo como idea.

  6. Yo no provengo de StringTemplate, provengo de Asp y trabajo con tecnologías Microsoft de toda mi vida. Conocí StringTemplate me sorprendió por exactamente lo opuesto a lo que comentas: StringTemplate es de hecho mucho más potente, flexible y elegante que T4. La gestión de memoria es la misma, ambos usan .Net y lo mismo aplica para los tipos, son tipos CTS, tipados o dinámicos, nombrados o anónimos, es exactamente lo mismo. No sé por qué afirmas eso cuando no hay ninguna diferencia.

    En cuanto a la integración con VS, eso sí, StringTemplate solo tiene coloreado de sintaxis y carece de intelisense porque no es necesario puesto que no podemos introducir código en las plantillas. Y además, puede usarse sin VS y puede formar parte de nuestro producto que va al cliente mientras que T4 no.

    La idea que propones suena bien pero no me parece práctico, imaginate crea un traductor para pasar de ST a T4 las cuales generan .cshtml que luego generan html con Razor…. demasiadas vueltas, prefiero aguanterme el dolor.

    Yo entiendo que quienes me leen no conozcan mucho fuera de Microsoft, pero realmente existe un gran mundo allá afuera. Es solo cuestión de animarse.

  7. Para mi T4 refleja fielmente «el estilo de pensar de MS». Eso puede ser bueno o malo, pero hay mucha gente que está acostumbrada a este estilo y lo encuentra más agradable (por costumbre).

    Tu lo dices Lucas. T4 viene a ser como ASP: mezclar código con salida final. Eso evita tener que aprender una nueva sintaxis, unas nuevas reglas para generar plantillas, a costa de una mayor «verbosidad».
    Yo mismo, que nunca he usado StringTemplate y nunca T4, entiendo mejor lo que hace la plantilla T4 que la de StringTemplate. Y con eso no digo que una sea mejor que otra, simplemente que la curva de aprendizaje de StringTemplate es superior.

    Un ejemplo parecido a esto, lo tienes en un post que puse hace tiempo para comparar dos generadores de HTML en cliente a partir de json. El primero jquery templates es estilo Microsoft (pues de MS proviene): se mezcla código con salida final. El segundo llamado PURE vendría a ser como StringTemplate: no hay código ni ninguna mezcla parecida (la propia plantilla es un objeto json). A mi PURE me gusta mucho, pero entiendo que el esfuerzo de meterse con él, es muy superior, lo que hace que al final la mayoría de la gente opte por jquery template. Pues con T4 y StringTemplate lo mismo 🙂

    Un saludo!

  8. Muy buen post lucas … thanks por compartir las experiencias y me apunto en dato para probar StringTemplate si alguna vez me toca pelear con un generador de código o similar 😀

    Salu2

Responder a etomas Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *