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?
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?
Respuestas:
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).
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.
namey itemspodría contener JavaScript.
¿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?
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.
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.
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.
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.
Hace que sus plantillas sean más limpias y lo obliga a mantener la lógica en un lugar donde se pueda probar adecuadamente.
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
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.
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.
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.
rowobjeto, en lugar de usar nombres estáticos. Por ejemplo, si $col.property == 'Something'entonces esto daría el contenido de row.Something.
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 :)
Las principales ventajas de utilizar plantillas sin lógica son:
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):