Qual è il vantaggio del modello senza logica (come i baffi)?


101

Recentemente, mi sono imbattuto in baffi che si afferma essere un modello senza logica .

Tuttavia, non si spiega perché sia ​​stato progettato in modo senza logica. In altre parole, qual è il vantaggio del modello senza logica?

Risposte:


107

In altre parole, ti impedisce di spararti ai piedi. Ai vecchi tempi di JSP, era molto comune avere file JSP cosparsi di codice Java, il che rendeva il refactoring molto più difficile, dal momento che il codice era sparso.

Se previeni la logica nei modelli in base alla progettazione (come fanno i baffi), sarai obbligato a mettere la logica altrove, quindi i tuoi modelli finiranno per essere ordinati.

Un altro vantaggio è che sei costretto a pensare in termini di separazione delle preoccupazioni: il tuo controller o codice logico dovrà eseguire il massaggio dei dati prima di inviare i dati all'interfaccia utente. Se in seguito cambi il tuo modello con un altro (supponiamo che inizi a utilizzare un motore di modelli diverso), la transizione sarebbe facile perché dovevi solo implementare i dettagli dell'interfaccia utente (poiché non c'è logica sul modello, ricorda).


30
Allora, perché è una buona cosa che il codice del controller DEVE massaggiare i dati esattamente nella forma necessaria per presentare i dati in un modo particolare? Perché è positivo che la modifica della presentazione richieda spesso la modifica del codice del controller? Questa mi sembra una brutta cosa. Pensavo che uno degli obiettivi di un linguaggio per modelli fosse separare la logica del controller dalla logica di presentazione. Un modello stupido che non può prendere alcuna decisione forza di nuovo la logica di presentazione nel codice del controller. Nelle organizzazioni in cui una persona diversa lavora alla presentazione, non può svolgere il proprio lavoro da sola.
jfriend00

8
Non preparare i dati per la visualizzazione nel controller. Il controller serve per controllare il flusso dell'applicazione. Invece quello che dovresti fare è creare una classe presentatore che trasformi il tuo modello in un modello di visualizzazione che viene poi utilizzato dalla vista. Un modello di visualizzazione è un modello per l'interfaccia utente separato dal modello che fa parte della logica di business. Ti consiglio di guardare il discorso "Clean Architecture and Design" di Robert "Uncle Bob" Martin: youtu.be/asLUTiJJqdE
ragol

1
Forza una certa logica di presentazione nel controller, ma questo aiuta a moltiplicare i vari livelli di presentazione. Se desideri che dati simili vengano presentati come JSON, HTML o XML, non dovresti distorcere i dati al 100% nel modello HTML. Ciò lascerebbe JSON e XML ad avere la propria logica di visualizzazione tortuosa. Stai centralizzando l'80% della logica di visualizzazione nel controller e incorporando l'altro 20% in lambda e filtri.
chugadie

65

Ho la sensazione di essere quasi solo secondo me, ma sono fermamente nel campo opposto. Non credo che la possibile combinazione di logica aziendale nei tuoi modelli sia una ragione sufficiente per non utilizzare tutta la potenza del tuo linguaggio di programmazione.

Il solito argomento per i modelli senza logica è che se hai pieno accesso al tuo linguaggio di programmazione potresti mescolare una logica che non ha posto in un modello. Lo trovo simile al ragionamento secondo cui dovresti usare un cucchiaio per affettare la carne perché potresti tagliarti se usi un coltello. Questo è molto vero, eppure sarai molto più produttivo se usi quest'ultimo, anche se con attenzione.

Ad esempio, considera il seguente frammento di modello utilizzando baffi :

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

Posso capirlo, ma trovo che quanto segue (usando il carattere di sottolineatura ) sia molto più semplice e diretto:

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

Detto questo, capisco che i modelli senza logica hanno dei vantaggi (ad esempio, possono essere utilizzati con più linguaggi di programmazione senza modifiche). Penso che questi altri vantaggi siano molto importanti. Semplicemente non credo che la loro natura priva di logica sia una di queste.


135
Sono sorpreso che tu senta che il modello di sottolineatura sia più semplice .. mi sembra molto meno leggibile. Solo un'opinione :-)
Ben Clayton

9
@ ben-clayton Sono d'accordo che la prima sintassi è più carina e forse più leggibile. Tuttavia, è la complessità a cui sto guidando quando dico "semplice".
brad

1
A volte l'uso di un'istruzione ternaria è appropriato nel modello, indipendentemente dalla logica che hai. O se volessi visualizzare il numero di elementi in un array? Non so come potrei usare i baffi, sembra che manchino cose del genere.
Paul Shapiro

5
@PaulShapiro Dovresti generare il numero di elementi nell'array al di fuori del modello e memorizzarlo in una variabile separata.
Seun Osewa

4
@brad, il modello di sottolineatura ha introdotto un buco XSS: namee itemspotrebbe contenere JavaScript.
Matteo

28

Moustache è senza logica?

Non è questo:

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

Abbastanza simile a questo?

if x
  "foo"
else
  "bar"
end

E non è che abbastanza simile a (leggi: quasi una definizione di) logica di presentazione?


17
Sì, se stai solo valutando la veridicità di un oggetto, ma provare a fare qualcosa di più complicato non è possibile ( if x > 0 && x < 10) ... Quindi, mentre è possibile usare Moustache con o senza logica, dipende da te. Dopotutto, è solo uno strumento.
Tom Ashworth,

5
Stai guardando la cosa nel modo sbagliato. Solo perché puoi fare alcune cose in una lingua che non sono esattamente del suo paradigma generale, non significa che la lingua non sia di quel paradigma. Puoi scrivere codice imperativo in Java o Haskell, ma non diresti che Java non è un linguaggio OO né Haskell non è un linguaggio funzionale. Guarda cosa ti permette di fare facilmente la lingua e verso cosa ti porta per vedere che tipo di lingua è.
cjs

@ CurtJ.Sampson la tua analogia avrebbe senso se Java si vendesse come "senza funzionalità" o se Haskell si vendesse come "senza oggetti". Questa risposta sta dimostrando che "senza logica" è nella migliore delle ipotesi un termine improprio.
Corey

1
Penso che tu sia d'accordo con me sul fatto che quando chiamiamo un linguaggio "funzionale" intendiamo "tendente al funzionale". Il disaccordo sembra essere che io definisco "X-less" come "allontanamento da X" mentre tu lo definisci come "completamente incapace di fare X".
cjs

13

Un modello senza logica è un modello che contiene dei buchi da riempire e non il modo in cui vengono riempiti. La logica viene posizionata altrove e mappata direttamente al modello. Questa separazione delle preoccupazioni è ideale perché quindi il modello può essere facilmente costruito con una logica diversa, o anche con un linguaggio di programmazione diverso.

Dal manuale dei baffi :

Lo chiamiamo "senza logica" perché non ci sono istruzioni if, clausole else o cicli for. Invece ci sono solo tag. Alcuni tag vengono sostituiti con un valore, altri niente e altri una serie di valori. Questo documento spiega i diversi tipi di tag Moustache.


6
La descrizione è leggermente sofisticata, poiché le sezioni funzionano piuttosto come condizionali e loop, solo molto limitati. La possibilità di fare riferimento a chiamabili nell'hash consente anche di trasformare le sezioni in un linguaggio di programmazione rudimentale. Tuttavia, almeno rende difficile percorrere quella strada, piuttosto che incoraggiarla.
Tom Anderson

1
Certo, ma un sistema di template senza blocchi per condizioni e iterazione sarebbe relativamente inutile. Il modello stesso non specifica a cosa serve il blocco o come viene gestito.
Jeremy

12

Il rovescio della medaglia è che nel disperato tentativo di mantenere la logica di business fuori dalla presentazione, si finisce per inserire molta logica di presentazione nel modello. Un esempio comune potrebbe essere quello di voler inserire classi "dispari" e "pari" su righe alternate in una tabella, operazione che potrebbe essere eseguita con un semplice operatore modulo nel modello di visualizzazione. Ma se il tuo modello di visualizzazione non ti consente di farlo, allora nei dati del tuo modello non devi solo memorizzare quale riga è pari o dispari, ma a seconda di quanto è limitato il tuo motore di modello, potresti persino dover inquinare il tuo modello con i nomi delle classi CSS effettive. Le viste dovrebbero essere separate dai modelli, punto. Ma i modelli dovrebbero anche essere indipendenti dalla vista, ed è questo che molti di questi motori di modelli "senza logica" ti fanno dimenticare. La logica va in entrambi i posti,in realtà fa per decidere correttamente dove va. È un problema di presentazione o un problema aziendale / dati? Nel tentativo di avere una vista incontaminata al 100%, l'inquinamento atterra in un altro luogo meno visibile ma ugualmente inappropriato.

C'è un crescente movimento di ritorno nella direzione opposta, e si spera che le cose si concentreranno da qualche parte nella più ragionevole via di mezzo.


6
Non sono d'accordo con te lì. La logica di presentazione per i modelli senza logica non va nel modello, ma nella vista, a cui appartiene. La visualizzazione prende i dati grezzi del modello e, se necessario, esegue i massaggi (annotando le righe pari / dispari, ecc.) Per prepararlo per la presentazione.
acjay

1
Perché le visualizzazioni non possono essere più di modelli e includere codice per massaggiare i dati per un modello?
LeeGee

1
acjohnson55 - Sono d'accordo con te su dove dovrebbe andare (vista), ma i modelli senza logica impediscono molto di questo. @LeeGee - Penso che ci sia un contraccolpo contro troppa logica nelle visualizzazioni, ma le cose sono andate troppo lontano nella direzione opposta per impedire anche la logica specifica della presentazione nelle visualizzazioni.
mattmc3

4
So di essere in ritardo alla festa, ma il CSS nth-item (dispari) dovrebbe essere usato per alternare i colori delle righe.
DanRedux

1
Non c'è niente di sbagliato nell'avere un oggetto di presentazione intermedio creato dalla vista da modelli e raccolte o qualsiasi altro dato. In questo modo, le viste creano dati di presentazione che vengono uniti a un modello per il rendering della vista.
wprl

11

Rende i tuoi modelli più puliti e ti costringe a mantenere la logica in un luogo in cui può essere adeguatamente testata.


2
Puoi spiegarlo con maggiori dettagli?
Morgan Cheng,

29
Trascorri tre mesi a lavorare su un sistema che utilizza un linguaggio logico per modelli, come JSP, con programmatori che non sono zelanti nel separare logica e presentazione. Scoprirai di creare un sistema che essenzialmente ha la programmazione nella pagina: aritmetica per il layout della tabella, condizionali per quali informazioni sui prezzi mostrare e così via. I linguaggi di creazione dei modelli sono linguaggi di programmazione estremamente poveri, quindi questo crea un incubo per lo sviluppo e la manutenzione. Qualcosa come Moustache non ti permette di entrare in quella situazione in primo luogo.
Tom Anderson

Se la logica ha la forma di una funzione, può essere utilizzata da un sistema di micro-template che supporta la logica incorporata e l' unità testata. L'idea peggiore per me sembra essere il manubrio "helper" (vedi spin.atomicobject.com/2011/07/14/… "Advanced Usage") - questi sembrerebbero impossibili da testare a causa del fatto che si trovano all'interno di script / tag di tipo / testo piuttosto che semplici tag di vecchio script (/ type / javascript)
Dexygen

8

Questa conversazione sembra come quando i monaci del Medioevo discutevano su quanti angeli possono stare all'estremità di uno spillo. In altre parole, inizia a sentirsi religioso, futile e focalizzato in modo errato.

Segue un mini-rant (sentiti libero di ignorare):

Se non vuoi continuare a leggere ... La mia breve risposta all'argomento precedente è: non sono d'accordo con i modelli senza logica. Lo considero una forma di programmazione dell'estremismo. :-) :-)

Ora il mio sproloquio continua a pieno ritmo: :-)

Penso che quando si portano molte idee all'estremo, il risultato diventa ridicolo. E a volte (cioè questo argomento) il problema è che portiamo l'idea "sbagliata" all'estremo.

Rimuovere tutta la logica dalla vista è "ridicolo" e l'idea sbagliata.

Fai un passo indietro per un momento.

La domanda che dobbiamo porci è: perché rimuovere la logica? Il concetto, ovviamente, è la separazione delle preoccupazioni . Mantieni l'elaborazione della vista il più separata possibile dalla logica aziendale. Perché fare questo? Ci consente di scambiare le visualizzazioni (per diverse piattaforme: mobile, browser, desktop ecc.) E ci consente di scambiare più facilmente il flusso di controllo, la sequenza di pagine, le modifiche di convalida, le modifiche al modello, l'accesso di sicurezza ecc. Anche quando la logica è rimosso dalle visualizzazioni (soprattutto visualizzazioni web), rende le visualizzazioni molto più leggibili e quindi più manutenibili. Lo capisco e sono d'accordo con quello.

Tuttavia, l'attenzione principale dovrebbe essere sulla separazione delle preoccupazioni. Non visualizzazioni senza logica al 100%. La logica all'interno delle viste dovrebbe riguardare come rendere il "modello". Per quanto mi riguarda, la logica nelle viste va benissimo. È possibile avere una logica di visualizzazione che non sia logica di business.

Sì, ai tempi in cui scrivevamo pagine JSP, PHP o ASP con poca o nessuna separazione tra logica del codice e logica di visualizzazione, la manutenzione di queste web-app era un vero incubo. Credimi, lo so, ho creato e poi mantenuto alcune di queste mostruosità. È stato durante quella fase di mantenimento che ho veramente capito (visceralmente) l'errore dei modi miei e dei miei colleghi. :-) :-)

Quindi l'editto dall'alto (gli esperti del settore) è diventato, devi strutturare le tue app web usando qualcosa come un controller di vista frontale (che viene inviato ai gestori o alle azioni [scegli il tuo framework web]) e le tue opinioni non devono contenere codice . I punti di vista dovevano diventare modelli stupidi.

Quindi concordo in generale con il sentimento di cui sopra, non per le specificità degli articoli dell'editto, ma piuttosto per la motivazione dietro l'editto - che è il desiderio di separare le preoccupazioni tra vista e logica aziendale.

In un progetto in cui sono stato coinvolto, abbiamo cercato di seguire l'idea di una visione senza logica fino all'estremo ridicolo. Avevamo un motore di modelli sviluppato internamente che ci avrebbe permesso di rendere gli oggetti del modello in html. Era un semplice sistema basato su token. È stato terribile per una ragione molto semplice. A volte in una vista dovevamo decidere, se visualizzare questo piccolo frammento di HTML .. o no .. La decisione è solitamente basata su un valore nel modello. Quando non hai assolutamente alcuna logica nella vista, come lo fai? Beh, non puoi. Ho avuto alcune discussioni importanti con il nostro architetto su questo. Le persone HTML front-end che scrivevano le nostre opinioni erano completamente ostacolate quando si trovavano di fronte a questo ed erano molto stressate perché non potevano raggiungere i loro obiettivi altrimenti semplici. Quindi ho introdotto il concetto di una semplice istruzione IF all'interno del nostro motore di modelli. Non posso descriverti il ​​sollievo e la calma che ne seguirono. Il problema è stato risolto con un semplice concetto di istruzione IF nei nostri modelli! All'improvviso il nostro motore di creazione dei modelli è diventato buono.

Allora come siamo finiti in questa situazione stressante sciocca? Ci siamo concentrati sull'obiettivo sbagliato. Abbiamo seguito la regola, non devi avere alcuna logica nelle tue opinioni. Quello era sbagliato. Penso che la "regola pratica" dovrebbe essere, ridurre al minimo quella quantità di logica nelle tue opinioni. Perché se non lo fai potresti inavvertitamente consentire alla logica aziendale di insinuarsi nella vista, il che viola la separazione delle preoccupazioni.

Capisco che quando dichiari che "Non devi avere logica nelle viste", diventa facile sapere quando sei un "buon" programmatore. (Se questa è la tua misura di bontà). Ora prova a implementare un'app Web di complessità anche media con la regola precedente. Non è così facile.

Per me, la regola della logica nelle visualizzazioni non è così chiara e francamente è lì che voglio che sia.

Quando vedo molta logica nelle viste, rilevo un odore di codice e cerco di eliminare la maggior parte della logica dalle viste - cerco di assicurarmi che la logica aziendale risieda altrove - cerco di separare le preoccupazioni. Ma quando comincio a chattare con persone che dicono che dobbiamo rimuovere ogni logica dalla vista, beh, per me, che sa solo di fanatismo, come so che puoi finire in situazioni come ho descritto sopra.

Ho finito con il mio sproloquio. :-)

Saluti,

David


ottima risposta, si tratta di buone pratiche di programmazione .. e tra l'altro, riutilizzare modelli senza logica nel server e nel client non è DRY perché dovrai duplicare la logica in entrambi ..
mateusmaso

5

Il miglior argomento che ho escogitato per i modelli senza logica è che puoi utilizzare gli stessi identici modelli sia sul client che sul server. Tuttavia non hai davvero bisogno di logica, solo una che ha il proprio "linguaggio". Sono d'accordo con le persone che si lamentano del fatto che i baffi limitano inutilmente. Grazie, ma sono un ragazzo grande e posso tenere puliti i miei modelli senza il tuo aiuto.

Un'altra opzione è trovare solo una sintassi di template che utilizzi un linguaggio supportato sia sul client che sul server, vale a dire javascript sul server utilizzando node.js oppure puoi utilizzare un interprete js e json tramite qualcosa come therubyracer.

Quindi potresti usare qualcosa come haml.js che è molto più pulito di tutti gli esempi forniti finora e funziona alla grande.


Sono completamente d'accordo. Dopo un po 'di lettura, sono giunto alla conclusione che la capacità di creare modelli in JS sia sul lato client che su quello server soddisfa le mie esigenze meglio di un mucchio di linguaggi di modellazione specifici
christofr

4

In una frase: Logic-less significa che il motore del modello stesso è meno complesso e quindi ha un footprint inferiore e ci sono meno modi per comportarsi in modo imprevisto.


3

Anche se la domanda è vecchia e ha una risposta, vorrei aggiungere il mio 2 ¢ (che può sembrare uno sproloquio, ma non lo è, si tratta di limitazioni e quando diventano inaccettabili).

L'obiettivo di un modello è eseguire il rendering di qualcosa, non eseguire la logica aziendale. Ora c'è una linea sottile tra non essere in grado di fare ciò che è necessario fare in un modello e avere "logica di business" in essi. Anche se ero molto positivo nei confronti di Moustache e ho provato a usarlo, alla fine non sono stato in grado di fare ciò di cui avevo bisogno in casi piuttosto semplici.

Il "massaggiare" dei dati (per usare le parole nella risposta accettata) può diventare un vero problema - non sono supportati nemmeno semplici percorsi (cosa a cui si rivolge Handlebars.js). Se ho i dati di visualizzazione e ho bisogno di modificarli ogni volta che voglio eseguire il rendering di qualcosa perché il mio motore di modelli è troppo limitante, questo non è utile alla fine. E sconfigge parte dell'indipendenza dalla piattaforma che i baffi rivendicano per sé; Devo duplicare ovunque la logica del massaggio.

Detto questo, dopo un po 'di frustrazione e dopo aver provato altri motori di modelli, abbiamo finito per creare il nostro (... ancora un altro ...), che utilizza una sintassi ispirata ai modelli .NET Razor. Viene analizzato e compilato sul server e genera una semplice funzione JS autonoma (in realtà come modulo RequireJS) che può essere invocata per "eseguire" il modello, restituendo una stringa come risultato. Il campione fornito da Brad sarebbe simile a questo quando si utilizza il nostro motore (che personalmente trovo di gran lunga superiore prontamente rispetto sia a Moustache che a Underscore):

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

Un'altra limitazione priva di logica ci ha colpito quando si chiamano parziali con Moustache. Sebbene i parziali siano supportati da Moustache, non è possibile personalizzare i dati da trasmettere per primi. Quindi, invece di essere in grado di creare un modello modulare e riutilizzare piccoli blocchi, finirò per creare modelli con codice ripetuto al loro interno.

Lo abbiamo risolto implementando un linguaggio di query ispirato a XPath, che abbiamo chiamato JPath. Fondamentalmente, invece di usare / per attraversare i bambini usiamo punti, e non solo stringhe, numeri e valori letterali booleani sono supportati ma anche oggetti e array (proprio come JSON). Il linguaggio è privo di effetti collaterali (che è un must per la creazione di modelli) ma consente di "massaggiare" i dati secondo necessità creando nuovi oggetti letterali.

Supponiamo di voler eseguire il rendering di una tabella "griglia di dati" con intestazioni personalizzabili e collegamenti ad azioni sulle righe, e successivamente aggiungere righe dinamicamente utilizzando jQuery. Le righe quindi devono essere in un parziale se non voglio duplicare il codice. Ed è qui che inizia il problema se alcune informazioni aggiuntive come quali colonne devono essere visualizzate fanno parte del viewmodel, e lo stesso per quelle azioni su ogni riga. Ecco un po 'di codice funzionante utilizzando il nostro modello e motore di query:

Modello di tabella:

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

Modello riga:

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

Invocazione dal codice JS:

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

Non contiene alcuna logica di business, tuttavia è riutilizzabile e configurabile ed è anche privo di effetti collaterali.


13
Onestamente non vedo il senso di questa risposta, non risponde affatto alla domanda. Dici che ci sono limitazioni senza descrivere effettivamente cosa sono o come si verificano. Alla fine ti lanci in una discussione sul tuo sistema che non è disponibile per nessun altro, in realtà potrebbe fare schifo e potrebbe finire un giorno sul quotidiano ma non lo sapremmo mai. Apri il codice sorgente, collegalo e lasciaci decidere!
mattmanser

1
@mattmanser, scrivo delle limitazioni che hanno portato a non utilizzare Moustache (e Handlebars): supporto mancante per percorsi, predicati, variabili, trasformazione dei dati per invocare i parziali. Erano tutti importanti per noi. Probabilmente un giorno renderemo open-source il codice, ma poiché è una soluzione lato server (o in fase di compilazione se lo desideri) che compila i modelli in codice JS, non avrà lo stesso vasto pubblico di Moustache. Se vuoi metterti in contatto, non esitare a contattarmi - sono anche l'autore di bsn GoldParser su Google code (dove puoi trovare facilmente la mia email nel file readme).
Lucero

Mi piace l'idea del tuo motore simile a un rasoio ... è open source?
Cracker

@Cracker, no, non è (ancora) - il "problema" con esso è che attualmente i modelli sono compilati in codice JS sul server che esegue ASP.NET MVC, e quindi il pubblico di destinazione non è grande come con altri motori di creazione di modelli . In aggiunta a ciò, fa parte di una libreria più grande che dobbiamo prima smontare per renderla open source.
Lucero

1
@Esailija Permette di specificare dinamicamente i nomi delle proprietà da prendere rowdall'oggetto, invece di usare nomi statici. Ad esempio, se $col.property == 'Something'questo restituisse il contenuto di row.Something.
Lucero

2

Ecco 3 modi per visualizzare un elenco, con il conteggio dei caratteri. Tutti tranne il primo e il più breve sono in linguaggi di template privi di logica.

CoffeeScript (con DSL Reactive Coffee builder) - 37 caratteri

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

Knockout - 100 caratteri

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

Manubrio / Moustache - 66 caratteri

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

Sottolineato: 87 caratteri

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

La promessa di modelli senza logica era, suppongo, che le persone con competenze più ampie sarebbero state in grado di gestire modelli senza logica senza spararsi sul piede. Tuttavia, quello che vedi negli esempi precedenti è che quando aggiungi un linguaggio a logica minimale al markup basato su stringhe, il risultato è più complesso, non meno. Inoltre, sembra che tu stia usando PHP della vecchia scuola.

Chiaramente non mi oppongo a mantenere la "logica di business" (calcoli estesi) fuori dai modelli. Ma penso che dando loro uno pseudo-linguaggio per la logica di visualizzazione invece di un linguaggio di prima classe, il prezzo venga pagato. Non solo più da scrivere, ma un atroce mix di cambio di contesto che qualcuno ha bisogno di leggerlo.

In conclusione, non riesco a vedere la logica dei modelli senza logica, quindi direi che il loro vantaggio è nullo per me, ma rispetto che molti nella comunità lo vedano in modo diverso :)


@ Brad, cosa ne pensate di questo confronto?
Dean Radcliffe

2

I principali vantaggi dell'utilizzo di modelli senza logica sono:

  • Applica rigorosamente la separazione della vista del modello , vedere questo documento per i dettagli (altamente consigliato)
  • Molto facile da capire e da usare , perché non è necessaria alcuna logica di programmazione (e conoscenza!) E la sintassi è minima
  • (in particolare Moustache) altamente portabile e indipendente dal linguaggio, può essere utilizzato senza modifiche in quasi tutti gli ambienti di programmazione

ottima risposta concisa!
MrWatson,

1

Sono d'accordo con Brad: lo underscorestile è più facile da capire. Ma devo ammettere che lo zucchero sintattico potrebbe non piacere a tutti. Se _.eachè un po 'confuso, puoi usare un forciclo tradizionale .

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

È sempre bello poter eseguire il fallback a costrutti standard come foro if. Usa <% if() %>o <% for() %>mentre Mustacheusi un po 'il neologismo per if-then-else(e confuso se non hai letto la documentazione):

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

Il motore dei modelli è ottimo quando puoi ottenere facilmente modelli nidificati ( underscorestile):

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

Fondamentalmente passi il tuo tmpl interiore come una proprietà del tuo contesto. E chiamalo di conseguenza. Dolce :)

A proposito, se l'unica cosa che ti interessa è il motore del modello, usa l'implementazione del modello autonomo. Sono solo 900 caratteri se minimizzati (4 righe lunghe):

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

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.