¿Cuál es la ventaja de la plantilla sin lógica (como el bigote)?

101

Recientemente, me encontré con un bigote que se dice que es una plantilla sin lógica .

Sin embargo, no hay explicación por qué está diseñado de manera sin lógica. En otras palabras, ¿cuál es la ventaja de la plantilla sin lógica?

Morgan Cheng
fuente

Respuestas:

107

En otras palabras, evita que te dispares en el pie. En los viejos tiempos de JSP, era muy común tener archivos JSP salpicados con código Java, lo que hacía que la refactorización fuera mucho más difícil, ya que tenía su código disperso.

Si evita la lógica en las plantillas por diseño (como lo hace el bigote), estará obligado a poner la lógica en otra parte, por lo que sus plantillas terminarán despejadas.

Otra ventaja es que se ve obligado a pensar en términos de separación de preocupaciones: su controlador o código lógico tendrá que realizar el masaje de datos antes de enviar datos a la interfaz de usuario. Si luego cambia su plantilla por otra (digamos que comienza a usar un motor de plantillas diferente), la transición sería fácil porque solo tenía que implementar los detalles de la interfaz de usuario (ya que no hay lógica en la plantilla, recuerde).

Miguel Ping
fuente
30
Entonces, ¿por qué es bueno que el código del controlador TIENE que manipular los datos exactamente en la forma que se necesita para presentar los datos de una manera particular? ¿Por qué es bueno que cambiar la presentación a menudo requiera cambiar el código del controlador? Esto me parece algo malo. Pensé que uno de los objetivos de un lenguaje de plantilla era separar la lógica del controlador de la lógica de presentación. Una plantilla tonta que no puede tomar ninguna decisión obliga a la lógica de presentación a volver al código del controlador. En organizaciones donde una persona diferente trabaja en la presentación, no pueden hacer su trabajo por sí mismos.
jfriend00
8
No debe preparar datos para la vista en su controlador. El controlador es para controlar el flujo de la aplicación. En cambio, lo que debe hacer es crear una clase de presentador que transforme su modelo en un modelo de vista que luego es consumido por la vista. Un modelo de vista es un modelo para la interfaz de usuario que está separado del modelo que forma parte de la lógica empresarial. Te recomiendo que veas la charla "Arquitectura y diseño limpios" de Robert "Uncle Bob" Martin: youtu.be/asLUTiJJqdE
ragol
1
Fuerza cierta lógica de presentación en el controlador, pero esto ayuda a múltiples capas de presentación. Si desea que se presenten datos similares como JSON, HTML o XML, no debe tergiversar los datos al 100% en la plantilla HTML. Eso dejaría que JSON y XML tuvieran su propia lógica de visualización retorcida. Está centralizando el 80% de la lógica de visualización en el controlador e incrustando el otro 20% en lambdas y filtros.
chugadie
65

Tengo la sensación de que estoy casi solo en mi opinión, pero estoy firmemente en el campo opuesto. No creo que la posible combinación de lógica empresarial en sus plantillas sea razón suficiente para no utilizar todo el poder de su lenguaje de programación.

El argumento habitual para las plantillas sin lógica es que si tiene acceso completo a su lenguaje de programación, puede mezclar lógica que no tiene lugar en una plantilla. Encuentro esto similar a razonar que debes usar una cuchara para cortar la carne porque podrías cortarte si usas un cuchillo. Esto es muy cierto y, sin embargo, será mucho más productivo si usa este último, aunque con cuidado.

Por ejemplo, considere el siguiente fragmento de plantilla con bigote :

{{name}}:
<ul>
  {{#items}}
    <li>{{.}}</li>
  {{/items}}
</ul>

Puedo entender esto, pero encuentro que lo siguiente (usando guión bajo ) es mucho más simple y directo:

<%- name %>:
<ul>
<% _.each(items, function(i){ %>
  <li><%- i %></li>
<% }); %>
</ul>

Dicho esto, entiendo que las plantillas sin lógica tienen ventajas (por ejemplo, se pueden usar con múltiples lenguajes de programación sin cambios). Creo que estas otras ventajas son muy importantes. Simplemente no creo que su naturaleza sin lógica sea uno de ellos.

puntilla
fuente
135
Me sorprende que sienta que la plantilla de subrayado es más simple ... me parece mucho menos legible. Solo una opinión :-)
Ben Clayton
9
@ ben-clayton Estoy de acuerdo en que la primera sintaxis es más bonita y quizás más legible. Sin embargo, es la complejidad a la que me refiero cuando digo "simple".
Brad
1
A veces, usar una declaración ternaria es apropiado en la plantilla sin importar la lógica que tenga. ¿O qué pasa si quiero generar la cantidad de elementos en una matriz? No sé cómo podría usar el bigote, parece que le faltan cosas así.
Paul Shapiro
5
@PaulShapiro Generaría la cantidad de elementos en la matriz fuera de la plantilla y la almacenaría en una variable separada.
Seun Osewa
4
@brad, la plantilla de subrayado introdujo un agujero XSS: namey itemspodría contener JavaScript.
Mateo
28

¿El bigote no tiene lógica?

No es esto:

{{#x}}
  foo
{{/x}}
{{^x}}
  bar
{{/x}}

¿Bastante similar a esto?

if x
  "foo"
else
  "bar"
end

¿Y no es eso bastante similar a (léase: casi una definición de) lógica de presentación?

pje
fuente
17
Sí, si solo está evaluando la veracidad de un objeto, pero no es posible intentar hacer algo más complicado ( if x > 0 && x < 10) ... Entonces, si bien es posible usar Moustache con o sin lógica, depende de usted. Después de todo, es solo una herramienta.
Tom Ashworth
5
Estás viendo esto de la manera incorrecta. El hecho de que pueda hacer algunas cosas en un idioma que no son exactamente de su paradigma general no significa que el idioma no sea de ese paradigma. Puede escribir código imperativo en Java o Haskell, pero no diría que eso hace que Java no sea un lenguaje OO ni que Haskell no sea un lenguaje funcional. Mira lo que el idioma te permite hacer fácilmente y hacia lo que te lleva para ver qué tipo de idioma es.
cjs
@ CurtJ.Sampson, su analogía tendría sentido si Java se vendiera a sí mismo como "sin funciones" o si Haskell se vendiera a sí mismo como "sin orientación a objetos". Esta respuesta demuestra que "sin lógica" es, en el mejor de los casos, un nombre inapropiado.
Corey
1
Creo que estás de acuerdo conmigo en que cuando llamamos "funcional" a un lenguaje queremos decir "que tiende a ser funcional". El desacuerdo parece ser que defino "sin X" como "tendiendo lejos de X" mientras que tú lo defines como "totalmente incapaz de hacer X".
cjs
13

Una plantilla sin lógica es una plantilla que contiene huecos para que los rellene, y no cómo los rellena. La lógica se coloca en otro lugar y se asigna directamente a la plantilla. Esta separación de preocupaciones es ideal porque entonces la plantilla se puede construir fácilmente con una lógica diferente, o incluso con un lenguaje de programación diferente.

Del manual del bigote :

Lo llamamos "sin lógica" porque no hay sentencias if, cláusulas else o bucles for. En cambio, solo hay etiquetas. Algunas etiquetas se reemplazan con un valor, otras con nada y otras con una serie de valores. Este documento explica los diferentes tipos de etiquetas Moustache.

Jeremy
fuente
6
La descripción es un poco sofisticada, ya que las secciones funcionan como condicionales y bucles, solo que muy limitadas. La capacidad de hacer referencia a las personas que llaman en el hash también le permite transformar secciones en un lenguaje de programación rudimentario. Aún así, al menos dificulta seguir ese camino, en lugar de alentarlo.
Tom Anderson
1
Claro, pero un sistema de plantilla sin bloques para condiciones e iteración sería relativamente inútil. La plantilla en sí no especifica para qué es el bloque ni cómo se maneja.
Jeremy
12

La otra cara de la moneda es que, en un intento desesperado por mantener la lógica empresarial fuera de la presentación, termina poniendo mucha lógica de presentación en el modelo. Un ejemplo común podría ser que desee poner clases "pares" e "impares" en filas alternas en una tabla, lo que podría hacerse con un operador de módulo simple en la plantilla de vista. Pero si su plantilla de vista no le permite hacer eso, entonces en los datos de su modelo no solo tiene que almacenar qué fila es par o impar, sino que dependiendo de cuán limitado sea su motor de plantilla, es posible que incluso necesite contaminar su modelo con los nombres de las clases CSS reales. Las vistas deben estar separadas de los modelos, punto final. Pero los modelos también deberían ser independientes de la vista, y eso es lo que muchos de estos motores de plantilla "sin lógica" te hacen olvidar. La lógica va en ambos lugares,realmente lo hace para decidir correctamente a dónde va. ¿Es un problema de presentación o un problema comercial o de datos? En un esfuerzo por tener vistas 100% prístinas, la contaminación simplemente aterriza en otro lugar menos visible pero igualmente inapropiado.

Hay un movimiento creciente de regreso en la otra dirección y , con suerte, las cosas se centrarán en algún punto intermedio más razonable.

mattmc3
fuente
6
Tengo que estar en desacuerdo contigo. La lógica de presentación de las plantillas sin lógica no va en el modelo, va en la vista, donde pertenece. La vista toma los datos del modelo sin procesar y los masajea según sea necesario (anotando filas pares / impares, etc.) para prepararlo para la presentación.
acjay
1
¿Por qué las vistas no pueden ser más que plantillas e incluir código para masajear los datos de una plantilla?
LeeGee
1
acjohnson55 - Estoy de acuerdo contigo acerca de dónde debería ir (ver), pero las plantillas sin lógica evitan mucho de eso. @LeeGee: creo que hay una reacción violenta contra demasiada lógica en las vistas, pero las cosas han ido demasiado lejos en la otra dirección para evitar incluso la lógica específica de la presentación en las vistas.
mattmc3
4
Sé que llego tarde a la fiesta, pero CSS nth-item (impar) debe usarse para alternar los colores de las filas.
DanRedux
1
No hay nada de malo en tener un objeto de presentación intermedio creado por la vista a partir de modelos y colecciones, o cualquier otro dato. De esta manera, las vistas crean datos de presentación que se combinan con una plantilla para representar la vista.
wprl
11

Hace que sus plantillas sean más limpias y lo obliga a mantener la lógica en un lugar donde se pueda probar adecuadamente.

estúpido
fuente
2
¿Puedes explicarlo con más detalles?
Morgan Cheng
29
Pase tres meses trabajando en un sistema que utilice un lenguaje de plantillas lógico, como JSP, con programadores que no son celosos de separar la lógica y la presentación. Descubrirá que construye un sistema que esencialmente tiene programación en la página: aritmética para el diseño de la tabla, condicionales para qué información de precios mostrar, etc. Los lenguajes de plantillas son lenguajes de programación extremadamente pobres, por lo que esto hace que el desarrollo y el mantenimiento sean una pesadilla. Algo como Moustache no te permite meterte en esa situación en primer lugar.
Tom Anderson
Si la lógica tiene la forma de una función, puede ser utilizada por un sistema de microplantillas que admita lógica incorporada y probada por unidad. Me parece que la peor idea son los "ayudantes" de los manillares (consulte spin.atomicobject.com/2011/07/14/… "Uso avanzado"); estos parecen imposibles de realizar pruebas unitarias debido a que están dentro del script / tipo / etiquetas de texto en lugar de etiquetas de script antiguas simples (/ tipo / javascript)
Dexygen
8

Esta conversación se siente como cuando los monjes de la Edad Media debatían sobre cuántos ángeles caben en el extremo de un alfiler. En otras palabras, empieza a sentirse religioso, inútil y mal enfocado.

Se produce una mini-perorata (no dude en ignorarla):

Si no desea seguir leyendo ... Mi breve respuesta al tema anterior es: No estoy de acuerdo con las plantillas sin lógica. Pienso en ello como una forma de programación de extremismo. :-) :-)

Ahora mi perorata continúa en pleno apogeo: :-)

Creo que cuando llevas muchas ideas al extremo, el resultado se vuelve ridículo. Y a veces (es decir, este tema) el problema es que llevamos la idea "incorrecta" al extremo.

Eliminar toda la lógica de la vista es "ridículo" y una idea equivocada.

Da un paso atrás por un momento.

La pregunta que debemos hacernos es ¿por qué eliminar la lógica? El concepto, obviamente, es separación de preocupaciones . Mantenga el procesamiento de la vista lo más separado posible de la lógica empresarial. ¿Por qué hacer esto? Nos permite intercambiar vistas (para diferentes plataformas: móvil, navegador, escritorio, etc.) y nos permite intercambiar más fácilmente el flujo de control, secuencia de página, cambios de validación, cambios de modelo, acceso de seguridad, etc. También cuando la lógica es eliminado de las vistas (especialmente las vistas web), hace que las vistas sean mucho más legibles y, por lo tanto, más fáciles de mantener. Lo entiendo y estoy de acuerdo con eso.

Sin embargo, el enfoque principal debería estar en la separación de preocupaciones. No vistas 100% sin lógica. La lógica dentro de las vistas debe relacionarse con cómo representar el "modelo". En lo que a mí respecta, la lógica en las opiniones está perfectamente bien. Puede tener una lógica de vista que no sea lógica de negocios.

Sí, en el día en que escribíamos páginas JSP, PHP o ASP con poca o ninguna separación de lógica de código y lógica de vista, el mantenimiento de estas aplicaciones web era una pesadilla absoluta. Créame, lo sé, creé y luego mantuve algunas de estas monstruosidades. Fue durante esa fase de mantenimiento que realmente entendí (visceralmente) el error de mi manera y la de mis colegas. :-) :-)

Entonces, el edicto de lo alto (los expertos de la industria) se convirtió en, debes estructurar tus aplicaciones web usando algo como un controlador de vista frontal (que se envía a los controladores o acciones [elige tu marco web]) y tus vistas no deben contener código . Las vistas se convertirían en plantillas tontas.

De modo que estoy de acuerdo en general con el sentimiento anterior, no por los aspectos específicos de los elementos del edicto, sino más bien por la motivación detrás del edicto, que es el deseo de separar las preocupaciones entre la visión y la lógica empresarial.

En un proyecto en el que participé, intentamos llevar la idea de la vista sin lógica hasta el extremo ridículo. Teníamos un motor de plantillas propio que nos permitía renderizar objetos de modelo en html. Era un sistema simple basado en tokens. Fue terrible por una razón muy simple. A veces, en una vista, teníamos que decidir si mostraba este pequeño fragmento de HTML ... o no ... La decisión generalmente se basa en algún valor del modelo. Cuando no tienes absolutamente ninguna lógica en la vista, ¿cómo lo haces? Bueno, no puedes. Tuve algunas discusiones importantes con nuestro arquitecto sobre esto. La gente de HTML de front-end que escribía nuestras vistas estaba completamente paralizada cuando se enfrentaron a esto y estaban muy estresados ​​porque no podían lograr sus objetivos que de otro modo serían simples. Así que presenté el concepto de una declaración IF simple dentro de nuestro motor de plantillas. No puedo describirle el alivio y la calma que siguió. ¡El problema se resolvió con un concepto simple de declaración IF en nuestras plantillas! De repente, nuestro motor de plantillas se volvió bueno.

Entonces, ¿cómo llegamos a esta situación estresante y tonta? Nos enfocamos en el objetivo equivocado. Seguimos la regla, no debe tener ninguna lógica en sus puntos de vista. Eso estuvo mal. Creo que la "regla empírica" ​​debería ser minimizar esa cantidad de lógica en sus puntos de vista. Porque si no lo hace, podría permitir inadvertidamente que la lógica empresarial se infiltre en la vista, lo que viola la separación de preocupaciones.

Entiendo que cuando declaras que "No debes tener lógica en las vistas", es fácil saber cuándo estás siendo un "buen" programador. (Si esa es tu medida de bondad). Ahora intente implementar una aplicación web de complejidad media incluso con la regla anterior. No es tan fácil de hacer.

Para mí, la regla de la lógica en las opiniones no es tan clara y, francamente, ahí es donde quiero que esté.

Cuando veo mucha lógica en las vistas, detecto un olor a código y trato de eliminar la mayor parte de la lógica de las vistas; trato de asegurarme de que la lógica empresarial viva en otra parte; trato de separar las preocupaciones. Pero cuando empiezo a charlar con personas que dicen que debemos quitar toda lógica de la vista, bueno, para mí, eso solo huele a fanatismo, ya que sé que puedes terminar en situaciones como las que describí anteriormente.

Terminé con mi perorata. :-)

Salud,

David

David Balme
fuente
gran respuesta, se trata de buenas prácticas de programación ... y, por cierto, reutilizar plantillas sin lógica en el servidor y el cliente no es DRY porque tendrá que duplicar la lógica en ambos ..
mateusmaso
5

El mejor argumento que se me ocurrió para las plantillas sin lógica es que puede usar exactamente las mismas plantillas tanto en el cliente como en el servidor. Sin embargo, en realidad no necesitas sin lógica, solo uno que tenga su propio "lenguaje". Estoy de acuerdo con las personas que se quejan de que el bigote limita inútilmente. Gracias, pero soy un niño grande y puedo mantener limpias mis plantillas sin tu ayuda.

Otra opción es simplemente encontrar una sintaxis de plantillas que use un lenguaje que sea compatible tanto en el cliente como en el servidor, es decir, javascript en el servidor, ya sea usando node.js o puede usar un intérprete js y json a través de algo como therubyracer.

Entonces podría usar algo como haml.js, que es mucho más limpio que cualquiera de los ejemplos proporcionados hasta ahora y funciona muy bien.

eagspoo
fuente
Estoy completamente de acuerdo. Después de leer un poco, llegué a la conclusión de que la capacidad de crear plantillas en JS tanto en el lado del cliente como en el del servidor satisface mis necesidades mejor que un montón de lenguajes de plantillas específicos
christofr
4

En una frase: Sin lógica significa que el motor de plantillas en sí es menos complejo y, por lo tanto, ocupa menos espacio y hay menos formas de comportarse de forma inesperada.

Kernel James
fuente
3

A pesar de que la pregunta es vieja y está respondida, me gustaría agregar mis 2 ¢ (que puede parecer una perorata, pero no lo es, se trata de limitaciones y cuándo se vuelven inaceptables).

El objetivo de una plantilla es renderizar algo, no realizar lógica empresarial. Ahora hay una delgada línea entre no poder hacer lo que necesita hacer en una plantilla y tener "lógica empresarial" en ellas. A pesar de que era muy positivo con Moustache y traté de usarlo, terminé sin poder hacer lo que necesito en casos bastante simples.

El "masaje" de los datos (para usar las palabras en la respuesta aceptada) puede convertirse en un problema real, ni siquiera se admiten rutas simples (algo que maneja Handlebars.js). Si tengo datos de vista y necesito modificarlos cada vez que quiero renderizar algo porque mi motor de plantillas es demasiado limitante, entonces esto no es útil al final. Y derrota parte de la independencia de plataforma que el bigote reclama para sí mismo; Tengo que duplicar la lógica del masaje en todas partes.

Dicho esto, después de un poco de frustración y después de probar otros motores de plantillas, terminamos creando el nuestro (... otro más ...), que usa una sintaxis inspirada en las plantillas de .NET Razor. Se analiza y compila en el servidor y genera una función JS simple y autónoma (en realidad, como módulo RequireJS) que puede invocarse para "ejecutar" la plantilla, devolviendo una cadena como resultado. La muestra dada por Brad se vería así cuando use nuestro motor (que personalmente encuentro muy superior en legibilidad en comparación con Moustache y Underscore):

@name:
<ul>
@for (items) {
  <li>@.</li>
}
</ul>

Otra limitación sin lógica nos golpea cuando llamamos a parciales con Moustache. Si bien Moustache admite los parciales, no hay posibilidad de personalizar los datos que se pasarán primero. Entonces, en lugar de poder crear una plantilla modular y reutilizar bloques pequeños, terminaré haciendo plantillas con código repetido en ellas.

Lo solucionamos implementando un lenguaje de consulta inspirado en XPath, al que llamamos JPath. Básicamente, en lugar de usar / para atravesar a los niños, usamos puntos, y no solo se admiten cadenas, números y literales booleanos, sino también objetos y matrices (como JSON). El lenguaje no tiene efectos secundarios (lo cual es imprescindible para crear plantillas) pero permite "masajear" datos según sea necesario mediante la creación de nuevos objetos literales.

Digamos que queremos representar una tabla de "cuadrícula de datos" con encabezados personalizables y enlaces a acciones en las filas, y luego agregar filas dinámicamente usando jQuery. Por lo tanto, las filas deben ser parciales si no quiero duplicar el código. Y ahí es donde comienza el problema si alguna información adicional, como qué columnas se renderizarán, son parte del modelo de vista, y lo mismo para esas acciones en cada fila. Aquí hay un código de trabajo real usando nuestra plantilla y motor de consulta:

Plantilla de tabla:

<table>
    <thead>
        <tr>
            @for (columns) {
                <th>@title</th>
            }
            @if (actions) {
                <th>Actions</th>
            }
        </tr>
    </thead>
    <tbody>
        @for (rows) {
            @partial Row({ row: ., actions: $.actions, columns: $.columns })
        }
    </tbody>
</table>

Plantilla de fila:

<tr id="@(row.id)">
    @for (var $col in columns) {
        <td>@row.*[name()=$col.property]</td>
    }
    @if (actions) {     
        <td>
        @for (actions) {
            <button class="btn @(id)" value="@(id)">@(name)...</button>
        }
        </td>
    }
</tr>

Invocación desde código JS:

var html = table({
    columns: [
        { title: "Username", property: "username" },
        { title: "E-Mail", property: "email" }
    ],
    actions: [
        { id: "delete", name: "Delete" }
    ],
    rows: GetAjaxRows()
})

No tiene ninguna lógica empresarial, pero es reutilizable y configurable, y tampoco tiene efectos secundarios.

Lucero
fuente
13
Honestamente, no veo el sentido de esta respuesta, no responde la pregunta en absoluto. Dice que hay limitaciones sin describir realmente qué son o cómo ocurren. Finalmente, se lanza a una discusión sobre su propio sistema que no está disponible para nadie más, en realidad podría ser una mierda y podría terminar algún día en thedailywtf, pero nunca lo sabremos. ¡Abre el código fuente, enlaza a él y déjanos decidir!
Mattmanser
1
@mattmanser, escribo sobre las limitaciones que llevaron a no usar Moustache (y Handlebars): falta de soporte para rutas, predicados, variables, transformación de datos para invocar parciales. Todos eran importantes para nosotros. Probablemente algún día abriremos el código, pero dado que es una solución del lado del servidor (o en tiempo de compilación si lo desea) que compila las plantillas en código JS, no tendrá la misma gran audiencia que Moustache. Si desea ponerse en contacto conmigo, no dude en ponerse en contacto conmigo; también soy el autor de bsn GoldParser en el código de Google (donde puede encontrar mi correo electrónico fácilmente en el archivo Léame).
Lucero
Me gusta la idea de tu maquinilla de afeitar como motor ... ¿es de código abierto?
Cracker
@Cracker, no, no lo es (todavía) - el "problema" es que actualmente las plantillas están compiladas en código JS en el servidor que ejecuta ASP.NET MVC y, por lo tanto, la audiencia objetivo no es tan grande como con otros motores de plantillas. . Además de eso, es parte de una biblioteca más grande que primero tenemos que desarmar para abrirla.
Lucero
1
@Esailija Permite especificar dinámicamente los nombres de las propiedades que se tomarán del rowobjeto, en lugar de usar nombres estáticos. Por ejemplo, si $col.property == 'Something'entonces esto daría el contenido de row.Something.
Lucero
2

Aquí hay 3 formas de representar una lista, con recuentos de caracteres. Todos menos el primero y el más corto están en lenguajes de plantillas sin lógica.

CoffeeScript (con DSL generador de café reactivo ) - 37 caracteres

"#{name}"
ul items.map (i) ->
  li i

Knockout - 100 caracteres

<span data-bind="value: name"/>
<ul data-bind="foreach: items">
   <li data-bind="value: i"/>
</ul>

Manillar / Bigote - 66 caracteres

{{name}}:
<ul>
  {{#items}}
    <li>{{.}}</li>
  {{/items}}
</ul>

Guión bajo - 87 caracteres

<%- name %>:
<ul>
<% _.each(items, function(i){ %>
  <li><%- i %></li>
<% }); %>
</ul>

La promesa de las plantillas sin lógica era, supongo, que las personas con habilidades más amplias podrían administrar plantillas sin lógica sin dispararse en el pie. Sin embargo, lo que ve en los ejemplos anteriores es que cuando agrega un lenguaje de lógica mínima al marcado basado en cadenas, el resultado es más complejo, no menos. Además, parece que estás usando PHP de la vieja escuela.

Claramente, no me opongo a mantener la "lógica de negocios" (computación extensa) fuera de las plantillas. Pero creo que dándoles un pseudolenguaje para la lógica de visualización en lugar de un lenguaje de primera clase, se paga el precio. No solo más para escribir, sino una mezcla atroz de cambios de contexto que alguien necesita leer.

En conclusión, no veo la lógica de las plantillas sin lógica, por lo que diría que su ventaja es nula para mí, pero respeto que muchos en la comunidad lo vean de manera diferente :)

Dean Radcliffe
fuente
@brad, ¿qué opinas de esta comparación?
Dean Radcliffe
2

Las principales ventajas de utilizar plantillas sin lógica son:

  • Refuerza estrictamente la separación de la vista del modelo ; consulte este documento para obtener más detalles (muy recomendado)
  • Muy fácil de entender y usar , porque no se necesita lógica de programación (¡ni conocimientos!) Y la sintaxis es mínima.
  • (particular Moustache) altamente portátil e independiente del lenguaje, se puede usar sin modificaciones en casi todos los entornos de programación
rmuller
fuente
gran respuesta concisa!
MrWatson
1

Estoy de acuerdo con Brad: el underscoreestilo es más fácil de entender. Pero debo admitir que el azúcar sintáctico puede no agradar a todos. Si _.eaches algo confuso, puede utilizar un forbucle tradicional .

  <% for(var i = 0; i < items.length; i++) { %>
    <%= items[i] %>
  <% } %>

Siempre es bueno si puede recurrir a construcciones estándar como foro if. Solo use <% if() %>o <% for() %>mientras Mustacheusa algo de neologismo para if-then-else(y confuso si no leyó la documentación):

{{#x}}
  foo
{{/x}}
{{^x}}
  bar
{{/x}}

El motor de plantillas es excelente cuando puede lograr plantillas anidadas fácilmente ( underscoreestilo):

<script id="items-tmpl" type="text/template">
    <ul>
        <% for(var i = 0; i < obj.items.length; i++) { %>
            <%= innerTmpl(obj.items[i]) %>
        <% } %>
    </ul>
</script>

<script id="item-tmpl" type="text/template">
    <li>
        <%= name %>
    </li>
</script>

var tmplFn = function(outerTmpl, innerTmpl) {
    return function(obj) {
        return outerTmpl({obj: obj, innerTmpl: innerTmpl});
    };
};

var tmpl = tmplFn($('#items-tmpl').html(), $('#item-tmpl').html());
var context = { items: [{name:'A',{name:'B'}}] };
tmpl(context);

Básicamente, pasas tu tmpl interno como una propiedad de tu contexto. Y llámalo en consecuencia. Dulce :)

Por cierto, si lo único que le interesa es el motor de plantillas, utilice la implementación de plantilla independiente. Tiene solo 900 caracteres cuando se reduce (4 líneas largas):

https://gist.github.com/marlun78/2701678

Roland
fuente