templates - sirve - tipos de barba
¿Cuál es la ventaja de la plantilla sin lógica(como el bigote)? (13)
¿Bigote no tiene lógica?
No es esto:
{{#x}}
foo
{{/x}}
{{^x}}
bar
{{/x}}
Muy similar a esto?
if x
"foo"
else
"bar"
end
¿Y no es eso bastante similar a (leer: casi una definición de) lógica de presentación?
Recientemente, me encontré con mustache que se dice que es una plantilla sin lógica .
Sin embargo, no hay ninguna explicación de por qué está diseñado de una manera sin lógica. En otras palabras, ¿cuál es la ventaja de la plantilla sin lógica?
Aquí hay 3 formas de hacer una lista, con recuentos de caracteres. Todos menos el primero y el más corto están en lenguajes sin plantillas de lógica.
CoffeeScript (con el generador de café reactivo DSL) - 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>
Subrayado - 87 caracteres
<%- name %>:
<ul>
<% _.each(items, function(i){ %>
<li><%- i %></li>
<% }); %>
</ul>
La promesa de plantillas sin lógica fue, supongo, que las personas con conjuntos de habilidades más amplios serían capaces de administrar plantillas sin lógica sin dispararse en el pie. Sin embargo, lo que se ve en los ejemplos anteriores es que cuando se 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 haciendo PHP de la vieja escuela.
Claramente, no me opongo a mantener la "lógica de negocios" (cálculo extenso) fuera de las plantillas. Pero creo que al darles un pseudo-lenguaje para la lógica de visualización en lugar de un lenguaje de primera clase, el precio es pagado. No solo más para escribir, sino una mezcla atroz de cambio de contexto que alguien necesita leer.
En conclusión, no veo la lógica de las plantillas sin lógica, así que diría que su ventaja es nula para mí, pero respeto que muchos en la comunidad lo vean de manera diferente :)
Aunque la pregunta es vieja y respondida, me gustaría agregar mi 2 ¢ (que puede sonar como una diatriba, pero no es así, se trata de limitaciones y cuando se vuelven inaceptables).
El objetivo de una plantilla es representar algo, no realizar lógica comercial. Ahora hay una delgada línea entre no poder hacer lo que tiene que hacer en una plantilla y tener "lógica comercial" en ellos. A pesar de que era muy positivo con Moustache y traté de usarlo, terminé sin poder hacer lo que necesitaba 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 sencillos caminos (algo que trata Handlebars.js). Si tengo datos de vista y necesito modificarlos cada vez que quiero renderizar algo porque el motor de mi plantilla es demasiado limitado, al final esto no es útil. Y derrota parte de la independencia de la plataforma que el bigote reclama por sí mismo; Tengo que duplicar la lógica de 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 .NET Razor. Se analiza y se compila en el servidor y genera una función JS simple e independiente (en realidad, como módulo RequireJS) que se puede invocar para "ejecutar" la plantilla y devolver una cadena como resultado. La muestra dada por brad se vería así cuando usamos nuestro motor (que personalmente encuentro muy superior en legibilidad en comparación con Bigote y Bajo puntaje):
@name:
<ul>
@for (items) {
<li>@.</li>
}
</ul>
Otra limitación sin lógica nos golpea cuando llamamos a parciales con Moustache. Si bien los parciales son compatibles con Moustache, no hay posibilidad de personalizar los datos que se pasarán primero. Entonces, en lugar de poder crear una plantilla modular y reutilizar pequeños bloques, terminaré haciendo plantillas con códigos repetidos.
Lo solucionamos implementando un lenguaje de consulta inspirado en XPath, 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 es libre de efectos secundarios (que es imprescindible para la creación de plantillas) pero permite "masajear" los datos según sea necesario al crear nuevos objetos literales.
Digamos que queremos representar una tabla de "cuadrícula de datos" con encabezados y enlaces cusomizables a acciones en las filas, y luego agregar dinámicamente filas usando jQuery. Por lo tanto, las filas deben estar en un parcial si no quiero duplicar el código. Y ahí es donde comienza el problema si alguna información adicional, como qué columnas se representarán, es 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 del 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 comercial, pero es reutilizable y configurable, y también es libre de efectos secundarios.
El mejor argumento que he encontrado para las plantillas sin lógica es que puedes usar exactamente las mismas plantillas tanto en el cliente como en el servidor. Sin embargo, realmente no necesita lógica, solo una que tenga su propio "lenguaje". Estoy de acuerdo con las personas que se quejan de que el bigote es inútilmente limitante. Gracias, pero soy un niño grande y puedo mantener mis plantillas limpias sin su ayuda.
Otra opción es simplemente encontrar una sintaxis de plantillas que use un lenguaje que sea compatible tanto con el cliente como con el servidor, es decir, javascript en el servidor, ya sea mediante node.js o puede usar un intérprete js y json a través de algo como therubyracer.
Entonces podrías usar algo como haml.js, que es mucho más limpio que cualquiera de los ejemplos proporcionados hasta ahora y funciona muy bien.
En otras palabras, evita que te dispares en el pie. En los viejos días JSP, era muy común tener archivos JSP salpicados de código Java, lo que dificultaba la refacturación, ya que tenía el código disperso.
Si previene la lógica en las plantillas por diseño (como bigote), se verá obligado a poner la lógica en otra parte, por lo que sus plantillas terminarán despejadas.
Otra ventaja es que se le obliga a pensar en términos de separación de preocupaciones: su controlador o código lógico tendrá que hacer el masaje de datos antes de enviar datos a la IU. Si luego cambia su plantilla por otra (digamos que comienza a utilizar un motor de plantillas diferente), la transición sería fácil porque solo tenía que implementar los detalles de la UI (ya que no hay lógica en la plantilla, recuerde).
En una frase: sin lógica significa que el motor de la plantilla en sí es menos complejo y, por lo tanto, tiene una huella más pequeña y hay menos formas de comportarse de forma inesperada.
Esta conversación se siente como cuando los monjes de la edad media debatirían sobre cuántos ángeles pueden caber en el extremo de un alfiler. En otras palabras, comienza a sentirse religioso, fútil e incorrectamente enfocado.
Se produce un mini-rant (no dude en ignorarlo):
Si no quiere seguir leyendo ... Mi breve respuesta al tema anterior es: No estoy de acuerdo con las plantillas sin lógica. Lo veo como una forma de programación del extremismo. :-) :-)
Ahora mi diatriba continúa en pleno apogeo: :-)
Creo que cuando llevas muchas ideas al extremo, el resultado se vuelve absurdo. Y a veces (es decir, este tema), el problema es que llevamos la idea "equivocada" al extremo.
Eliminar toda la lógica de la vista es "absurdo" y la 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 la separación de las preocupaciones . Mantenga el procesamiento de la vista por separado de la lógica comercial como sea posible. ¿Por qué hacer esto? Nos permite intercambiar puntos de vista (para diferentes plataformas: móvil, navegador, computadora de escritorio, etc.) y nos permite intercambiar más fácilmente el flujo de control, la secuencia de páginas, los cambios de validación, los cambios de modelo, el 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 primordial debería ser la separación de las preocupaciones. No es 100% de vistas sin lógica. La lógica dentro de las vistas debe relacionarse con cómo renderizar el "modelo". En lo que a mí respecta, la lógica en los puntos de vista está perfectamente bien. Puede tener view-logic que no sea business-logic.
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 visualización, el mantenimiento de estas aplicaciones web era una auténtica pesadilla. Créeme, lo sé, creé y luego mantuve algunas de estas monstruosidades. Fue durante esa fase de mantenimiento que realmente entendí (visceralmente) el error de mi y mis colegas. :-) :-)
Así que el edicto de lo alto (los expertos de la industria) se convirtió, debes estructurar tus aplicaciones web usando algo como un controlador de vista frontal (que se distribuye a los controladores o acciones [elige tu web-framework]) y tus vistas no deben contener código . Los puntos de vista debían convertirse en plantillas tontas.
Así que estoy de acuerdo en general con el sentimiento anterior, no por los detalles de los ítems 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 comercial.
En un proyecto en el que participé, tratamos de seguir la idea de la vista sin lógica hasta el extremo ridículo. Teníamos un motor de plantillas propio que nos permitía representar objetos modelo en html. Era un sistema simple basado en tokens. Fue terrible por una razón muy simple. A veces, en una vista, tuvimos que decidir si mostrar este pequeño fragmento de HTML ... o no. La decisión se basa generalmente en algún valor en el modelo. Cuando no tienes absolutamente ninguna lógica en la vista, ¿cómo lo haces? Bueno, no puedes. Tuve algunos argumentos importantes con nuestro arquitecto sobre esto. Las personas de HTML que escribían nuestros puntos de vista estaban completamente bloqueadas cuando se enfrentaron con esto y estaban muy estresadas porque no podían alcanzar sus objetivos, que de otro modo serían simples. Así que introduje el concepto de una declaración de IF simple dentro de nuestro motor de plantillas. No puedo describirte el alivio y la calma que siguieron. ¡El problema fue resuelto con un simple concepto de declaración IF en nuestras plantillas! De repente, nuestro motor de plantillas se volvió bueno.
Entonces, ¿cómo nos metimos en esta estresante situación estúpida? Nos enfocamos en el objetivo equivocado. Seguimos la regla, no debes tener ninguna lógica en tus puntos de vista. Eso estuvo mal. Creo que la "regla empírica" debería ser, minimizar la 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 las preocupaciones.
Entiendo que cuando declaras que "No debes tener lógica en los puntos de vista", 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 incluso de complejidad media con la regla anterior. No es tan fácil de hacer.
Para mí, la regla de la lógica en los puntos de vista 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 -todo intento para asegurar que la lógica de negocios viva en otra parte- trato de separar las preocupaciones. Pero cuando comienzo a chatear con personas que dicen que debemos eliminar toda la lógica de la vista, bueno, para mí, eso huele a fanatismo ya que sé que puedes terminar en situaciones como las descritas arriba.
Terminé mi diatriba. :-)
Aclamaciones,
David
Estoy de acuerdo con Brad: el estilo de underscore es más fácil de entender. Pero debo admitir que el azúcar sintáctico puede no ser del agrado de todos. Si _.each es algo confuso, puede usar un bucle for tradicional.
<% for(var i = 0; i < items.length; i++) { %>
<%= items[i] %>
<% } %>
Siempre es bueno si puede recurrir a construcciones estándar como for o if . Solo use <% if() %> o <% for() %> mientras que Mustache usa un poco de neologismo para if-then-else (y confunde si no leyó la documentación):
{{#x}}
foo
{{/x}}
{{^x}}
bar
{{/x}}
El motor de plantillas es excelente cuando puedes lograr plantillas anidadas fácilmente (estilo de underscore ):
<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, use la implementación de la plantilla independiente. Tiene solo 900 caracteres cuando se minimiza (4 líneas largas):
Hace que sus plantillas sean más limpias y le obliga a mantener la lógica en un lugar donde pueda ser probada de forma adecuada.
La otra cara de la moneda es que en un intento desesperado por mantener la lógica comercial fuera de la presentación, terminas poniendo mucha lógica de presentación en el modelo. Un ejemplo común podría ser que desee colocar clases "impares" y "pares" 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 debe almacenar qué fila es impar o par, sino que dependiendo de qué tan limitado esté el motor de su plantilla, es posible que deba contaminar su modelo con los nombres de las clases de CSS reales. Las vistas deben estar separadas de los modelos, punto completo. Pero los Modelos también deben ser Ver agnósticos, y eso es lo que muchos de estos motores de plantillas "sin lógica" te hacen olvidar. La lógica va en ambos lugares, pero debes ser juicioso sobre lo que la lógica realmente hace para decidir dónde va correctamente. ¿Es una preocupación de presentación, o una preocupación de negocio / datos? En un esfuerzo por tener puntos de vista 100% prístinos, 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 lugar en el medio más razonable.
Las principales ventajas de usar plantillas sin lógica son:
- Exige estrictamente la separación de la vista modelo , consulte este documento para obtener detalles (altamente recomendado)
- Muy fácil de entender y usar , porque no se necesita lógica de programación (¡y conocimiento!) Y la sintaxis es mínima
- (particular Moustache) altamente portátil e independiente del lenguaje, se puede utilizar sin modificaciones en casi todos los entornos de programación
Me da la sensación de estar 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 las plantillas sea motivo suficiente para no utilizar toda la potencia 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 en lógica que no tiene lugar en una plantilla. Encuentro esto similar al razonamiento de que debes usar una cuchara para cortar carne porque podrías cortártelo si usas un cuchillo. Esto es muy cierto, y sin embargo, será mucho más productivo si utiliza el último, aunque con cuidado.
Por ejemplo, considere el siguiente fragmento de plantilla con mustache :
{{name}}:
<ul>
{{#items}}
<li>{{.}}</li>
{{/items}}
</ul>
Puedo entender esto, pero me parece que lo siguiente (usando underscore ) 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 una de ellas.
Una plantilla sin lógica es una plantilla que contiene agujeros para que llene, y no cómo los llena. 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 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. En cambio, solo hay etiquetas. Algunas etiquetas se reemplazan con un valor, algunas nada, y otras una serie de valores. Este documento explica los diferentes tipos de etiquetas de bigote.