Qual é a vantagem do modelo sem lógica (como bigode)?


101

Recentemente, encontrei um bigode que afirma ser um modelo sem lógica .

No entanto, não há nenhuma explicação de por que ele foi projetado de forma sem lógica. Em outras palavras, qual é a vantagem do modelo sem lógica?

Respostas:


107

Em outras palavras, impede que você dê um tiro no próprio pé. Nos velhos tempos de JSP, era muito comum ter arquivos JSP polvilhados com código Java, o que tornava a refatoração muito mais difícil, já que seu código estava espalhado.

Se você evitar a lógica nos modelos por design (como o bigode faz), será obrigado a colocar a lógica em outro lugar, de modo que seus modelos ficarão organizados.

Outra vantagem é que você é forçado a pensar em termos de separação de interesses: seu controlador ou código lógico terá que fazer a massagem de dados antes de enviar os dados para a IU. Se mais tarde você trocar seu modelo por outro (digamos que você comece a usar um mecanismo de modelo diferente), a transição seria fácil porque você só precisava implementar os detalhes da IU (uma vez que não há lógica no modelo, lembre-se).


30
Então, por que é uma coisa boa que o código do controlador TENHA que massagear os dados exatamente da forma necessária para apresentar os dados de uma maneira particular? Por que é bom que a alteração da apresentação geralmente exija a alteração do código do controlador? Isso parece uma coisa ruim para mim. Achei que um dos objetivos de uma linguagem de modelo era separar a lógica do controlador da lógica de apresentação. Um modelo burro que não pode tomar nenhuma decisão força a lógica de apresentação de volta ao código do controlador. Em organizações onde uma pessoa diferente trabalha na apresentação, eles não podem fazer seu trabalho por conta própria.
jfriend00

8
Você não deve preparar dados para a visualização em seu controlador. O controlador serve para controlar o fluxo do aplicativo. Em vez disso, o que você deve fazer é criar uma classe de apresentador que transforma seu modelo em um modelo de visualização que é então consumido pela visualização. Um modelo de visualização é um modelo para a IU separado do modelo que faz parte da lógica de negócios. Eu recomendo que você assista a palestra "Clean Arquitetura e Design" por Robert "Tio Bob" Martin: youtu.be/asLUTiJJqdE
Ragol

1
Ele força alguma lógica de apresentação no controlador, mas ajuda a várias camadas de apresentação. Se você deseja que dados semelhantes sejam apresentados como JSON, HTML ou XML, não deve torcer os dados 100% no modelo HTML. Isso deixaria o JSON e o XML com sua própria lógica de exibição de torção. Você está centralizando 80% da lógica de exibição no controlador e incorporando os outros 20% em lambdas e filtros.
chugadie

65

Tenho a sensação de que estou quase sozinho na minha opinião, mas estou firmemente no campo oposto. Não acredito que a possível combinação de lógica de negócios em seus modelos seja razão suficiente para não usar todo o poder de sua linguagem de programação.

O argumento usual para modelos sem lógica é que, se você tiver acesso total à sua linguagem de programação, poderá misturar lógica que não tem lugar em um modelo. Acho que isso se assemelha ao raciocínio de que você deve usar uma colher para cortar carne, porque você pode se cortar se usar uma faca. Isso é verdade, mas você será muito mais produtivo se usar o último, embora com cuidado.

Por exemplo, considere o seguinte snippet de modelo usando bigode :

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

Eu posso entender isso, mas acho o seguinte (usando o sublinhado ) muito mais simples e direto:

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

Dito isso, eu entendo que os modelos sem lógica têm vantagens (por exemplo, eles podem ser usados ​​com várias linguagens de programação sem alterações). Acho que essas outras vantagens são muito importantes. Só não acho que sua natureza sem lógica seja uma delas.


135
Estou surpreso que você sinta que o modelo de sublinhado é mais simples ... parece muito menos legível para mim. Apenas uma opinião :-)
Ben Clayton

9
@ ben-clayton Eu concordo que a primeira sintaxe é mais bonita e talvez mais legível. No entanto, é a complexidade que eu quero chegar quando digo "simples".
brad

1
Às vezes, usar uma declaração ternária é apropriado no modelo, não importa a lógica que você tenha. Ou e se eu quiser gerar o número de itens em uma matriz? Não sei como usar bigode, parece que faltam coisas assim.
Paul Shapiro

5
@PaulShapiro Você geraria o número de itens no array fora do modelo e o armazenaria em uma variável separada.
Seun Osewa

4
@brad, o modelo de sublinhado introduziu um buraco XSS: namee itemspode conter JavaScript.
Mateus,

28

O bigode não tem lógica?

Não é este:

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

Muito parecido com isso?

if x
  "foo"
else
  "bar"
end

E isso não é muito semelhante à (leia-se: quase uma definição de) lógica de apresentação?


17
Sim, se você está apenas avaliando a veracidade de um objeto, mas tentar fazer algo mais complicado não é possível ( if x > 0 && x < 10) ... Então, embora seja possível usar o Bigode com ou sem lógica, você decide. Afinal, é apenas uma ferramenta.
Tom Ashworth

5
Você está olhando para isso da maneira errada. Só porque você pode fazer algumas coisas em uma linguagem que não são exatamente de seu paradigma geral, não significa que a linguagem não seja desse paradigma. Você pode escrever código imperativo em Java ou Haskell, mas você não diria que isso torna Java não uma linguagem OO nem Haskell não uma linguagem funcional. Veja o que a linguagem permite que você faça facilmente e para onde isso o leva para ver que tipo de linguagem é.
cjs

@ CurtJ.Sampson, sua analogia faria sentido se Java se vendesse como "menos funcional" ou se Haskell se vendesse como "menos orientado a objetos". Essa resposta está demonstrando que "sem lógica" é, na melhor das hipóteses, um termo impróprio.
Corey,

1
Acho que você concorda comigo que, quando chamamos uma linguagem de "funcional", queremos dizer "tendendo para funcional". A discordância parece ser que eu defino "sem X" como "tendendo para longe de X", enquanto você o define como "totalmente incapaz de fazer X".
cjs

13

Um modelo sem lógica é um modelo que contém buracos para você preencher, e não como você os preenche. A lógica é colocada em outro lugar e mapeada diretamente para o modelo. Essa separação de interesses é ideal porque o modelo pode ser facilmente construído com uma lógica diferente ou mesmo com uma linguagem de programação diferente.

Do manual do bigode :

Chamamos isso de "sem lógica" porque não há instruções if, cláusulas else ou loops for. Em vez disso, existem apenas tags. Algumas tags são substituídas por um valor, outras nada e outras por uma série de valores. Este documento explica os diferentes tipos de tags Mustache.


6
A descrição é ligeiramente sofisticada, já que as seções funcionam como condicionais e loops, apenas alguns muito limitados. A capacidade de se referir a chamáveis ​​no hash também permite transformar seções em uma linguagem de programação rudimentar. Ainda assim, pelo menos torna-se difícil seguir esse caminho, em vez de encorajá-lo.
Tom Anderson,

1
Claro, mas um sistema de template sem blocos para condições e iteração seria relativamente inútil. O modelo em si não especifica para que serve o bloco ou como ele é tratado.
Jeremy

12

O outro lado da moeda é que, em uma tentativa desesperada de manter a lógica de negócios fora da apresentação, você acaba colocando muita lógica de apresentação no modelo. Um exemplo comum pode ser que você queira colocar classes "ímpares" e "pares" em linhas alternadas em uma tabela, o que pode ser feito com um operador de módulo simples no modelo de visualização. Mas se o seu modelo de visualização não permite que você faça isso, então nos dados do seu modelo você não deve apenas armazenar qual linha é ímpar ou par, mas dependendo de quão limitado é o seu mecanismo de modelo, você pode até mesmo precisar poluir o seu modelo com os nomes das classes CSS reais. As visualizações devem ser separadas de Modelos, ponto final. Mas os modelos também devem ser agnósticos quanto ao modo de exibição, e é isso que muitos desses mecanismos de modelo "sem lógica" fazem você esquecer. A lógica vai em ambos os lugares,realmente faz para decidir corretamente para onde vai. É uma questão de apresentação ou de negócios / dados? Em um esforço para ter 100% de vistas primitivas, a poluição apenas pousa em outro lugar menos visível, mas igualmente inadequado.

Há um movimento crescente de volta na outra direção e , com sorte, as coisas vão se concentrar em algum lugar no meio-termo mais razoável.


6
Tenho que discordar de você aí. A lógica de apresentação para modelos sem lógica não vai no modelo, vai na visualização, a que pertence. A visualização pega os dados brutos do modelo e faz a massagem conforme necessário (anotando linhas ímpares / pares etc.) para prepará-los para a apresentação.
acjay

1
Por que as visualizações não podem ser mais do que modelos e incluir código para massagear os dados de um modelo?
LeeGee

1
acjohnson55 - Eu concordo com você sobre onde deve ir (ver), mas os modelos sem lógica evitam muito disso. @LeeGee - Acho que há uma reação contra o excesso de lógica nas visualizações, mas as coisas foram longe demais na outra direção para impedir até mesmo a lógica específica da apresentação nas visualizações.
mattmc3

4
Sei que estou atrasado para a festa, mas o enésimo item CSS (ímpar) deve ser usado para alternar cores de linha.
DanRedux

1
Não há nada de errado em ter um objeto de apresentação intermediário criado pela visualização de modelos e coleções, ou quaisquer outros dados. Desta forma, as visualizações criam dados de apresentação que são mesclados com um modelo para renderizar a visualização.
wprl

11

Isso torna seus modelos mais limpos e força você a manter a lógica em um lugar onde possa ser devidamente testada na unidade.


2
Você pode explicar com mais detalhes?
Morgan Cheng,

29
Passe três meses trabalhando em um sistema usando uma linguagem de modelagem lógica, como JSP, com programadores que não são zelosos em separar lógica e apresentação. Você descobrirá que construiu um sistema que essencialmente tem programação na página - aritmética para o layout da tabela, condições para que informações de preço mostrar e assim por diante. Linguagens de modelagem são linguagens de programação extremamente pobres, então isso torna o desenvolvimento e a manutenção um pesadelo. Algo como Mustache não permite que você entre nessa situação em primeiro lugar.
Tom Anderson,

Se a lógica estiver na forma de uma função, ela pode ser usada por um sistema de microtemplating que suporta lógica incorporada e testada por unidade. A pior ideia para mim parece ser "ajudantes" de guiador (veja spin.atomicobject.com/2011/07/14/… "Uso avançado") - estes parecem ser impossíveis de teste de unidade devido a estarem dentro do script / tags de tipo / texto em vez de tags de script simples (/ type / javascript)
Dexygen

8

Essa conversa parece quando os monges da Idade Média debatiam sobre quantos anjos cabem na ponta de um alfinete. Em outras palavras, está começando a se sentir religioso, fútil e focado incorretamente.

Segue-se um mini-discurso (sinta-se à vontade para ignorar):

Se você não quiser continuar lendo ... Minha resposta curta ao tópico acima é: Não concordo com os modelos sem lógica. Eu penso nisso como uma forma de programação de extremismo. :-) :-)

Agora meu discurso continua a todo vapor: :-)

Acho que quando você leva muitas ideias ao extremo, o resultado se torna ridículo. E às vezes (isto é, este tópico), o problema é que levamos a ideia "errada" ao extremo.

Remover toda a lógica da visão é "ridículo" e uma ideia errada.

Dê um passo para trás por um momento.

A pergunta que precisamos nos fazer é por que remover a lógica? O conceito, obviamente, é separação de interesses . Mantenha o processamento da visualização o mais separado possível da lógica de negócios. Por que fazer isso? Ele nos permite trocar visualizações (para plataformas diferentes: móvel, navegador, desktop, etc.) e nos permite trocar mais facilmente o fluxo de controle, sequência de página, alterações de validação, alterações de modelo, acesso de segurança, etc. Também quando a lógica é removido das visualizações (especialmente visualizações da web), torna as visualizações muito mais legíveis e, portanto, mais fáceis de manter. Eu entendo isso e concordo com isso.

No entanto, o foco principal deve ser na separação de interesses. Visualizações não 100% sem lógica. A lógica dentro das visualizações deve se relacionar a como renderizar o "modelo". No que me diz respeito, a lógica nas visualizações é perfeitamente adequada. Você pode ter uma lógica de exibição que não seja uma lógica de negócios.

Sim, no tempo em que escrevíamos páginas JSPs, PHP ou ASP com pouca ou nenhuma separação entre lógica de código e lógica de exibição, a manutenção desses aplicativos da web era um pesadelo absoluto. Acredite, eu sei, eu criei e depois mantive algumas dessas monstruosidades. Foi durante essa fase de manutenção que realmente entendi (visceralmente) o erro dos meus caminhos e dos dos meus colegas. :-) :-)

Assim, o édito do alto (os especialistas da indústria) tornou-se, você deve estruturar seus aplicativos da web usando algo como um controlador de visão frontal (que despacha para manipuladores ou ações [escolha sua estrutura da web]) e suas visualizações não devem conter código . As visualizações se tornariam modelos estúpidos.

Portanto, concordo em geral com o sentimento acima, não pelas especificidades dos itens do edital, mas sim pela motivação por trás do edital - que é o desejo de separações de preocupações entre visão e lógica de negócios.

Em um projeto em que estive envolvido, tentamos seguir a ideia da visão sem lógica ao extremo ridículo. Tínhamos um mecanismo de template desenvolvido internamente que nos permitiria renderizar objetos de modelo em html. Era um sistema simples baseado em tokens. Foi terrível por um motivo muito simples. Às vezes, em uma visão, tínhamos que decidir se devo exibir este pequeno trecho de HTML ... ou não ... A decisão geralmente é baseada em algum valor no modelo. Quando você não tem absolutamente nenhuma lógica em vista, como você faz isso? Bem, você não pode. Tive algumas discussões importantes com nosso arquiteto sobre isso. O pessoal de HTML do front-end que escreveu nossas visualizações ficou completamente paralisado quando se deparou com isso e ficou muito estressado porque não poderia atingir seus objetivos simples. Então, apresentei o conceito de uma instrução IF simples em nosso mecanismo de modelagem. Não posso descrever para você o alívio e a calma que se seguiram. O problema foi resolvido com um conceito simples de declaração IF em nossos modelos! De repente, nosso motor de modelagem ficou bom.

Então, como entramos nessa situação tola e estressante? Nós nos concentramos no objetivo errado. Seguimos a regra, você não deve ter nenhuma lógica em suas opiniões. Isso estava errado. Eu acho que a "regra de ouro" deve ser, minimizar essa quantidade de lógica em suas opiniões. Porque se você não fizer isso, você pode inadvertidamente permitir que a lógica de negócios apareça na visão - o que viola a separação de interesses.

Eu entendo que quando você declara que "Você não deve ter lógica nas visualizações", fica fácil saber quando você está sendo um "bom" programador. (Se essa é sua medida de bondade). Agora tente implementar um aplicativo da web até mesmo de complexidade média com a regra acima. Não é tão fácil de fazer.

Para mim, a regra da lógica nas visualizações não é tão clara e, francamente, é onde eu quero que esteja.

Quando vejo muita lógica nas visualizações, detecto um cheiro de código e tento eliminar a maior parte da lógica das visualizações - tento garantir que a lógica de negócios resida em outro lugar - tento separar as preocupações. Mas quando começo a conversar com pessoas que dizem que devemos remover toda a lógica da visão, bem, para mim, isso soa como fanatismo, pois sei que você pode acabar em situações como as que descrevi acima.

Estou farto do meu discurso retórico. :-)

Felicidades,

David


ótima resposta, é tudo sobre boas práticas de programação .. e, a propósito, reutilizar modelos sem lógica no servidor e no cliente não é SECO porque você terá que duplicar a lógica em ambos ..
mateusmaso

5

O melhor argumento que inventei para modelos sem lógica é que você pode usar exatamente os mesmos modelos no cliente e no servidor. No entanto, você realmente não precisa do sem lógica, apenas um que tenha sua própria "linguagem". Concordo com as pessoas que se queixam de que o bigode é limitador inutilmente. Obrigado, mas sou um menino crescido e posso manter meus modelos limpos sem a sua ajuda.

Outra opção é apenas encontrar uma sintaxe de modelo que usa uma linguagem com suporte no cliente e no servidor, ou seja, javascript no servidor usando node.js ou você pode usar um interpretador js e json por meio de algo como therubyracer.

Então você poderia usar algo como haml.js, que é muito mais limpo do que qualquer um dos exemplos fornecidos até agora e funciona muito bem.


Eu concordo completamente. Após alguma leitura, cheguei à conclusão de que a capacidade de criar modelos em JS tanto no lado do cliente quanto no servidor atende às minhas necessidades melhor do que um monte de linguagens de modelagem específicas
christofr

4

Em uma frase: Sem lógico significa que o mecanismo de modelo em si é menos complexo e, portanto, ocupa menos espaço e há menos maneiras de se comportar inesperadamente.


3

Mesmo que a pergunta seja antiga e respondida, gostaria de adicionar meus 2 centavos (o que pode soar como um discurso retórico, mas não é, é sobre limitações e quando elas se tornam inaceitáveis).

O objetivo de um modelo é renderizar algo, não executar lógica de negócios. Agora, há uma linha tênue entre não ser capaz de fazer o que você precisa fazer em um modelo e ter "lógica de negócios" neles. Mesmo sendo muito otimista em relação ao Mustache e tentado usá-lo, acabei não conseguindo fazer o que preciso em casos bem simples.

A "massagem" dos dados (para usar as palavras na resposta aceita) pode se tornar um problema real - nem mesmo caminhos simples são suportados (algo que o Handlebars.js aborda). Se eu tiver dados de exibição e precisar ajustá-los toda vez que quiser renderizar algo porque meu mecanismo de modelo é muito limitado, isso não será útil no final. E derrota parte da independência de plataforma que o bigode reivindica para si; Tenho que duplicar a lógica de massagem em todos os lugares.

Dito isso, depois de alguma frustração e depois de tentar outros motores de template, acabamos criando o nosso próprio (... mais um ...), que usa uma sintaxe inspirada nos templates .NET Razor. Ele é analisado e compilado no servidor e gera uma função JS simples e autocontida (na verdade, como módulo RequireJS) que pode ser chamada para "executar" o modelo, retornando uma string como resultado. A amostra fornecida por brad ficaria assim ao usar nosso motor (que pessoalmente considero muito superior em legibilidade em comparação com o bigode e o sublinhado):

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

Outra limitação sem lógica nos atingiu ao chamar parciais com Mustache. Embora parciais sejam suportados pelo Mustache, não há possibilidade de personalizar os dados a serem transmitidos primeiro. Portanto, em vez de ser capaz de criar um modelo modular e reutilizar pequenos blocos, acabarei fazendo modelos com código repetido neles.

Resolvemos isso implementando uma linguagem de consulta inspirada em XPath, que chamamos de JPath. Basicamente, em vez de usar / para atravessar para os filhos, usamos pontos, e não apenas strings, números e literais booleanos são suportados, mas também objetos e matrizes (assim como JSON). A linguagem não tem efeitos colaterais (o que é obrigatório para modelos), mas permite "massagear" os dados conforme necessário, criando novos objetos literais.

Digamos que queremos renderizar uma tabela de "grade de dados" com cabeçalhos personalizáveis ​​e links para ações nas linhas e, posteriormente, adicionar linhas dinamicamente usando jQuery. As linhas, portanto, precisam ser parciais se eu não quiser duplicar o código. E é aí que começa o problema se algumas informações adicionais, como quais colunas devem ser renderizadas, fizerem parte do modelo de visualização, e o mesmo para essas ações em cada linha. Aqui estão alguns códigos reais de trabalho usando nosso modelo e mecanismo de consulta:

Modelo de tabela:

<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>

Modelo de linha:

<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>

Invocação do código JS:

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

Ele não tem nenhuma lógica de negócios, mas é reutilizável e configurável, além de não ter efeitos colaterais.


13
Sinceramente, não vejo o sentido dessa resposta, ela não responde à pergunta de forma alguma. Você diz que há limitações sem realmente descrever o que são ou como ocorrem. Finalmente, você começa a discutir seu próprio sistema, que não está disponível para mais ninguém; na realidade, ele pode ser uma merda e pode acabar um dia no wtf diário, mas nunca saberemos. Abra o código, faça um link e deixe-nos decidir!
mattmanser de

1
@mattmanser, eu escrevo sobre as limitações que levaram ao não uso de Mustache (e Handlebars): suporte ausente para caminhos, predicados, variáveis, transformação de dados para invocar parciais. Tudo isso foi importante para nós. Provavelmente iremos abrir o código-fonte do código algum dia, mas como é uma solução do lado do servidor (ou tempo de compilação, se você quiser) que compila os modelos para o código JS, não terá o mesmo grande público que o Mustache. Se quiser entrar em contato, sinta-se à vontade para entrar em contato comigo - também sou o autor de bsn GoldParser no código do Google (onde você pode encontrar meu e-mail facilmente no arquivo leia-me).
Lucero

Gosto da ideia do seu motor em forma de navalha ... é de código aberto?
Cracker

@Cracker, não, não é (ainda) - o "problema" com isso é que atualmente os modelos são compilados em código JS no servidor que executa a ASP.NET MVC e, portanto, o público-alvo não é tão grande quanto com outros motores de modelos . Além disso, é parte de uma biblioteca maior que primeiro temos que desmontar para disponibilizar o código-fonte aberto.
Lucero

1
@Esailija Permite especificar nomes de propriedades dinamicamente a serem retirados do rowobjeto, em vez de usar nomes estáticos. Por exemplo, se $col.property == 'Something'então isso resultaria no conteúdo de row.Something.
Lucero

2

Aqui estão 3 maneiras de renderizar uma lista, com contagens de caracteres. Todos, exceto o primeiro e o mais curto, estão em linguagens de modelagem sem lógica.

CoffeeScript (com o construtor Reactive Coffee 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>

Guiador / bigode - 66 caracteres

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

Sublinhado - 87 caracteres

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

A promessa de modelos sem lógica era, suponho, que pessoas com conjuntos de habilidades mais amplos seriam capazes de gerenciar modelos sem lógica sem dar um tiro no próprio pé. No entanto, o que você vê nos exemplos acima é que, quando você adiciona uma linguagem de lógica mínima à marcação baseada em string, o resultado é mais complexo, não menos. Além disso, parece que você está fazendo PHP da velha escola.

Obviamente, não me oponho a manter a "lógica de negócios" (computação extensiva) fora dos modelos. Mas acho que, ao dar a eles uma pseudo-linguagem para lógica de exibição em vez de uma linguagem de primeira classe, o preço está pago. Não apenas mais para digitar, mas uma mistura hedionda de mudança de contexto que alguém precisa ler.

Concluindo, não consigo ver a lógica dos modelos sem lógica, então eu diria que sua vantagem é nula para mim, mas eu respeito o fato de muitos na comunidade verem isso de forma diferente :)


@brad, o que você acha dessa comparação?
Dean Radcliffe de

2

As principais vantagens de usar modelos sem lógica são:

  • Impõe estritamente a separação modelo-visualização , consulte este documento para obter detalhes (altamente recomendado)
  • Muito fácil de entender e usar , porque nenhuma lógica de programação (e conhecimento!) É necessária e a sintaxe é mínima
  • (em particular Bigode) altamente portátil e independente de linguagem, pode ser usado sem modificação em quase todos os ambientes de programação

ótima resposta concisa!
MrWatson

1

Concordo com o Brad: o underscoreestilo é mais fácil de entender. Mas devo admitir que o açúcar sintático pode não agradar a todos. Se _.eachfor um pouco confuso, você pode usar um forloop tradicional .

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

É sempre bom se você puder recorrer a construções padrão, como forou if. Basta usar <% if() %>ou <% for() %>enquanto Mustacheusa um pouco de neologismo para if-then-else(e confuso se você não leu a documentação):

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

O mecanismo de modelo é ótimo quando você pode obter modelos aninhados facilmente ( 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);

Basicamente, você passa seu tmpl interno como uma propriedade de seu contexto. E chamá-lo de acordo. Doce :)

A propósito, se a única coisa em que você está interessado é o mecanismo de template, use a implementação de template independente. Possui apenas 900 caracteres quando reduzido (4 linhas longas):

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

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.