Quel est l'avantage du modèle sans logique (comme la moustache)?

101

Récemment, je suis tombé sur une moustache qui est prétendument un modèle sans logique .

Cependant, rien n'explique pourquoi il est conçu de manière sans logique. En un autre mot, quel est l'avantage du modèle sans logique?

Morgan Cheng
la source

Réponses:

107

En d'autres termes, cela vous empêche de vous tirer une balle dans le pied. Dans l'ancien temps des JSP, il était très courant d'avoir des fichiers JSP saupoudrés de code Java, ce qui rendait le refactoring beaucoup plus difficile, car votre code était dispersé.

Si vous empêchez la logique dans les modèles par conception (comme le fait moustache), vous serez obligé de mettre la logique ailleurs, de sorte que vos modèles finiront par être épurés.

Un autre avantage est que vous êtes obligé de penser en termes de séparation des préoccupations: votre contrôleur ou code logique devra faire le massage des données avant d'envoyer les données à l'interface utilisateur. Si vous changez plus tard votre modèle pour un autre (disons que vous commencez à utiliser un moteur de modèle différent), la transition serait facile car vous ne deviez implémenter que les détails de l'interface utilisateur (car il n'y a pas de logique sur le modèle, rappelez-vous).

Miguel Ping
la source
30
Alors, pourquoi est-ce une bonne chose que le code du contrôleur DOIT masser les données exactement sous la forme nécessaire pour présenter les données d'une manière particulière? Pourquoi est-ce une bonne chose que changer la présentation nécessite souvent de changer le code du contrôleur? Cela me semble une mauvaise chose. Je pensais que l'un des objectifs d'un langage de modèle était de séparer la logique du contrôleur de la logique de présentation. Un modèle stupide qui ne peut prendre aucune décision contraint la logique de présentation à revenir dans le code du contrôleur. Dans les organisations où une personne différente travaille sur la présentation, ils ne peuvent pas faire leur travail par eux-mêmes.
jfriend00
8
Vous ne devez pas préparer les données pour la vue dans votre contrôleur. Le contrôleur sert à contrôler le flux des applications. Au lieu de cela, vous devez créer une classe de présentateur qui transforme votre modèle en un modèle de vue qui est ensuite consommé par la vue. Un modèle de vue est un modèle pour l'interface utilisateur qui est distinct du modèle qui fait partie de la logique métier. Je vous recommande de regarder la conférence "Clean Architecture and Design" de Robert "Oncle Bob" Martin: youtu.be/asLUTiJJqdE
ragol
1
Cela force une certaine logique de présentation dans le contrôleur, mais cela permet de multiplier les différentes couches de présentation. Si vous souhaitez que des données similaires soient présentées au format JSON, HTML ou XML, vous ne devez pas tordre les données à 100% dans le modèle HTML. Cela laisserait le JSON et le XML avoir leur propre logique d'affichage de torsion. Vous centralisez 80% de la logique d'affichage dans le contrôleur et intégrez les 20% restants dans les lambdas et les filtres.
chugadie le
65

J'ai le sentiment que je suis presque seul à mon avis, mais je suis fermement dans le camp opposé. Je ne pense pas que le mélange possible de logique métier dans vos modèles soit une raison suffisante pour ne pas utiliser toute la puissance de votre langage de programmation.

L'argument habituel des modèles sans logique est que si vous avez un accès complet à votre langage de programmation, vous pouvez mélanger une logique qui n'a pas sa place dans un modèle. Je trouve que cela s'apparente au raisonnement selon lequel vous devriez utiliser une cuillère pour trancher la viande, car vous pourriez vous couper si vous utilisez un couteau. C'est très vrai, et pourtant vous serez beaucoup plus productif si vous utilisez ce dernier, bien que prudemment.

Par exemple, considérez l'extrait de modèle suivant à l'aide de moustache :

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

Je peux comprendre cela, mais je trouve que ce qui suit (en utilisant un trait de soulignement ) est beaucoup plus simple et direct:

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

Cela étant dit, je comprends que les modèles sans logique présentent des avantages (par exemple, ils peuvent être utilisés avec plusieurs langages de programmation sans modifications). Je pense que ces autres avantages sont très importants. Je ne pense tout simplement pas que leur nature sans logique en soit une.

Brad
la source
135
Je suis surpris que vous trouviez que le modèle de soulignement est plus simple ... il me semble beaucoup moins lisible. Juste un avis :-)
Ben Clayton
9
@ ben-clayton Je suis d'accord que la première syntaxe est plus jolie et peut-être plus lisible. Cependant, c'est la complexité à laquelle je conduis quand je dis «simple».
brad
1
Parfois, l'utilisation d'une instruction ternaire est appropriée dans le modèle, quelle que soit la logique que vous avez. Ou que faire si je veux afficher le nombre d'éléments dans un tableau? Je ne sais pas comment je pourrais utiliser la moustache, il semble qu'il manque des choses comme ça.
Paul Shapiro
5
@PaulShapiro Vous généreriez le nombre d'éléments dans le tableau en dehors du modèle et le stockeriez dans une variable distincte.
Seun Osewa
4
@brad, le modèle de soulignement a introduit un trou XSS: nameet itemspourrait contenir du JavaScript.
Matthieu
28

La moustache est sans logique?

N'est-ce pas:

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

Assez similaire à ça?

if x
  "foo"
else
  "bar"
end

Et n'est pas que assez similaire à (lire: presque une définition de) la logique de présentation?

pje
la source
17
Oui, si vous évaluez simplement la véracité d'un objet, mais essayer de faire quelque chose de plus compliqué n'est pas possible ( if x > 0 && x < 10) ... Donc, s'il est possible d'utiliser Moustache avec ou sans logique, c'est à vous de décider. Après tout, ce n'est qu'un outil.
Tom Ashworth
5
Vous regardez cela de la mauvaise façon. Ce n'est pas parce que vous pouvez faire certaines choses dans une langue qui ne sont pas exactement de son paradigme général que la langue n'est pas de ce paradigme. Vous pouvez écrire du code impératif en Java ou Haskell, mais vous ne diriez pas que Java n'est pas un langage OO ni Haskell n'est pas un langage fonctionnel. Regardez ce que la langue vous permet de faire facilement et vers quoi elle vous mène pour voir de quel type de langue il s'agit.
cjs
@ CurtJ.Sampson, votre analogie aurait du sens si Java se vendait comme "sans fonction" ou si Haskell se vendait comme "sans orienté objet". Cette réponse démontre que «sans logique» est au mieux un abus de langage.
Corey
1
Je pense que vous êtes d'accord avec moi que lorsque nous appelons un langage «fonctionnel», nous entendons «tendant vers le fonctionnel». Le désaccord semble être que je définis "X-less" comme "tendant à s'éloigner de X" alors que vous le définissez comme "totalement incapable de faire X".
cjs
13

Un modèle sans logique est un modèle qui contient des trous à remplir, et non la façon dont vous les remplissez. La logique est placée ailleurs et mappée directement sur le modèle. Cette séparation des préoccupations est idéale car alors le modèle peut facilement être construit avec une logique différente, ou même avec un langage de programmation différent.

Du manuel de la moustache :

Nous l'appelons "sans logique" car il n'y a pas d'instructions if, else ou de boucles for. Au lieu de cela, il n'y a que des balises. Certaines balises sont remplacées par une valeur, d'autres rien et d'autres une série de valeurs. Ce document explique les différents types de balises Moustache.

Jérémie
la source
6
La description est un peu sophistiquée, car les sections fonctionnent plutôt comme des conditionnelles et des boucles, mais très limitées. La possibilité de faire référence à des éléments appelables dans le hachage vous permet également de transformer des sections en un langage de programmation rudimentaire. Pourtant, au moins, il est difficile de suivre cette voie, plutôt que de l'encourager.
Tom Anderson
1
Bien sûr, mais un système de modèle sans blocs pour les conditions et l'itération serait relativement inutile. Le modèle lui-même ne spécifie pas à quoi sert le bloc ni comment il est géré.
Jeremy
12

Le revers de la médaille est que dans une tentative désespérée de garder la logique métier hors de la présentation, vous finissez par mettre beaucoup de logique de présentation dans le modèle. Un exemple courant pourrait être que vous souhaitiez placer des classes «impaires» et «paires» sur des lignes alternées dans une table, ce qui pourrait être fait avec un simple opérateur modulo dans le modèle de vue. Mais si votre modèle de vue ne vous permet pas de le faire, dans vos données de modèle, vous devez non seulement stocker quelle ligne est paire ou impaire, mais en fonction de la limitation de votre moteur de modèle, vous devrez peut-être même polluer votre modèle. avec les noms des classes CSS réelles. Les vues doivent être séparées des modèles, point final. Mais les modèles doivent également être indépendants de la vue, et c'est ce que beaucoup de ces moteurs de modèles «sans logique» vous font oublier. La logique va aux deux endroits,fait réellement pour décider correctement où il va. S'agit-il d'un problème de présentation ou d'un problème commercial / de données? Dans un effort pour avoir une vue à 100% vierge, la pollution atterrit simplement dans un autre endroit moins visible mais tout aussi inapproprié.

Il y a un mouvement croissant de retour dans l'autre sens, et j'espère que les choses se centreront quelque part dans le terrain d'entente plus raisonnable.

mattmc3
la source
6
Je ne suis pas d'accord avec toi. La logique de présentation des modèles sans logique ne va pas dans le modèle, elle va dans la vue, où elle appartient. La vue prend les données brutes du modèle et les masse si nécessaire (en annotant les lignes paires / impaires, etc.) pour la préparer à la présentation.
acjay
1
Pourquoi les vues ne peuvent-elles pas être plus que des modèles et inclure du code pour masser les données d'un modèle?
LeeGee
1
acjohnson55 - Je suis d'accord avec vous sur la destination (vue), mais les modèles sans logique en empêchent beaucoup. @LeeGee - Je pense qu'il y a un contrecoup contre trop de logique dans les vues, mais les choses sont allées trop loin dans l'autre sens pour empêcher même la logique spécifique à la présentation dans les vues.
mattmc3
4
Je sais que je suis en retard à la fête, mais CSS nth-item (impair) devrait être utilisé pour alterner les couleurs des lignes.
DanRedux
1
Il n'y a rien de mal à avoir un objet de présentation intermédiaire créé par la vue à partir de modèles et de collections, ou de toute autre donnée. De cette manière, les vues créent des données de présentation qui sont fusionnées avec un modèle pour rendre la vue.
wprl
11

Cela rend vos modèles plus propres et vous oblige à conserver la logique dans un endroit où elle peut être correctement testée à l'unité.

imbécile
la source
2
Pouvez-vous l'expliquer avec plus de détails?
Morgan Cheng
29
Passez trois mois à travailler sur un système utilisant un langage de modélisation logique, comme JSP, avec des programmeurs qui ne sont pas zélés pour séparer la logique et la présentation. Vous constaterez que vous construisez un système qui a essentiellement une programmation dans la page - arithmétique pour la mise en page des tableaux, conditions pour les informations de tarification à afficher, etc. Les langages de modèles sont des langages de programmation extrêmement pauvres, ce qui en fait un cauchemar de développement et de maintenance. Quelque chose comme Moustache ne vous laisse pas entrer dans cette situation en premier lieu.
Tom Anderson
Si la logique est sous la forme d'une fonction, elle peut être utilisée par un système de micro-modèles prenant en charge la logique intégrée et testée par unité. La pire idée me semble être les "helpers" du guidon (voir spin.atomicobject.com/2011/07/14/… "Advanced Usage") - ceux-ci semblent impossibles à tester unitaire car ils sont dans le script / balises de type / texte plutôt que de vieilles balises de script (/ type / javascript)
Dexygen
8

Cette conversation ressemble à celle où les moines du moyen-âge débattraient du nombre d'anges pouvant tenir au bout d'une épingle. En d'autres termes, il commence à se sentir religieux, futile et mal focalisé.

Un mini-coup de gueule s'ensuit (n'hésitez pas à ignorer):

Si vous ne voulez pas continuer à lire ... Ma réponse courte au sujet ci-dessus est: Je ne suis pas d'accord avec les modèles sans logique. Je pense que c'est une forme de programmation d'extrémisme. :-) :-)

Maintenant, ma diatribe continue en plein essor: :-)

Je pense que lorsque l'on pousse beaucoup d'idées à l'extrême, le résultat devient ridicule. Et parfois (c'est-à-dire ce sujet) le problème est que nous poussons la «mauvaise» idée à l'extrême.

Supprimer toute logique de la vue est "ridicule" et une mauvaise idée.

Reculez un instant.

La question que nous devons nous poser est de savoir pourquoi supprimer la logique? Le concept est évidemment la séparation des préoccupations . Gardez le traitement de la vue aussi séparé que possible de la logique métier. Pourquoi faire ceci? Cela nous permet d'échanger des vues (pour différentes plates-formes: mobile, navigateur, bureau, etc.) et cela nous permet d'échanger plus facilement le flux de contrôle, la séquence de pages, les changements de validation, les changements de modèle, l'accès à la sécurité, etc. retiré des vues (en particulier des vues Web), il rend les vues beaucoup plus lisibles et donc plus faciles à gérer. Je comprends cela et je suis d'accord avec cela.

Cependant, l'accent doit être mis avant tout sur la séparation des préoccupations. Pas des vues 100% sans logique. La logique dans les vues doit se rapporter à la façon de rendre le «modèle». En ce qui me concerne, la logique dans les vues est parfaitement bien. Vous pouvez avoir une logique de vue qui n'est pas une logique métier.

Oui, à l'époque où nous écrivions des pages JSP, PHP ou ASP avec peu ou pas de séparation de la logique du code et de la logique de vue, la maintenance de ces applications Web était un cauchemar absolu. Croyez-moi, je sais, j'ai créé puis entretenu certaines de ces monstruosités. C'est pendant cette phase de maintenance que j'ai vraiment compris (viscéralement) l'erreur de mes manières et de mes collègues. :-) :-)

Ainsi, l'édit d'en haut (les experts de l'industrie) est devenu, vous devez structurer vos applications Web en utilisant quelque chose comme un contrôleur de vue de face (qui est envoyé aux gestionnaires ou aux actions [choisissez votre cadre Web]) et vos vues ne doivent contenir aucun code . Les vues devaient devenir des modèles stupides.

Je suis donc en général d'accord avec le sentiment ci-dessus, non pas pour les spécificités des éléments de l'édit, mais plutôt pour la motivation derrière l'édit - qui est le désir de séparer les préoccupations entre la vue et la logique commerciale.

Dans un projet auquel j'ai participé, nous avons essayé de suivre l'idée de la vue sans logique à l'extrême ridicule. Nous avions un moteur de modèle maison qui nous permettrait de rendre les objets de modèle en html. C'était un simple système basé sur des jetons. C'était terrible pour une raison très simple. Parfois, dans une vue, nous devions décider, devrais-je afficher ce petit bout de code HTML .. ou pas .. La décision est généralement basée sur une valeur dans le modèle. Quand vous n'avez absolument aucune logique dans la vue, comment faites-vous cela? Eh bien, vous ne pouvez pas. J'ai eu des arguments majeurs avec notre architecte à ce sujet. Les personnes HTML frontales qui écrivaient nos points de vue étaient complètement bloquées quand elles étaient confrontées à cela et étaient très stressées parce qu'elles ne pouvaient pas atteindre leurs objectifs autrement simples. J'ai donc introduit le concept d'une simple instruction IF dans notre moteur de création de modèles. Je ne peux pas vous décrire le soulagement et le calme qui s'en sont suivis. Le problème a été résolu avec un simple concept IF-Statement dans nos modèles! Soudain, notre moteur de création de modèles est devenu bon.

Alors, comment sommes-nous arrivés dans cette situation de stress ridicule? Nous nous sommes concentrés sur le mauvais objectif. Nous avons suivi la règle, vous ne devez avoir aucune logique dans vos vues. C'était faux. Je pense que la "règle de base" devrait être de minimiser cette quantité de logique dans vos vues. Parce que si vous ne le faites pas, vous pourriez par inadvertance laisser la logique métier s'infiltrer dans la vue - ce qui viole la séparation des préoccupations.

Je comprends que lorsque vous déclarez que "Vous ne devez avoir aucune logique dans les vues", il devient facile de savoir quand vous êtes un "bon" programmeur. (Si c'est votre mesure de la bonté). Maintenant, essayez d'implémenter une application Web de complexité même moyenne avec la règle ci-dessus. Ce n'est pas si facile à faire.

Pour moi, la règle de la logique dans les vues n'est pas si claire et franchement c'est là que je veux qu'elle soit.

Quand je vois beaucoup de logique dans les vues, je détecte une odeur de code et j'essaie d'éliminer la plupart de la logique des vues - j'essaie de m'assurer que la logique métier est ailleurs - j'essaie de séparer les préoccupations. Mais quand je commence à discuter avec des gens qui disent que nous devons supprimer toute logique de la vue, eh bien, pour moi, cela sent juste le fanatisme car je sais que vous pouvez vous retrouver dans des situations comme je l'ai décrit ci-dessus.

J'ai fini ma diatribe. :-)

À votre santé,

David

David Balme
la source
excellente réponse, il s'agit de bonnes pratiques de programmation .. et au fait, la réutilisation de modèles sans logique dans le serveur et le client n'est pas DRY car vous devrez dupliquer la logique dans les deux ..
mateusmaso
5

Le meilleur argument que j'ai trouvé pour les modèles sans logique est que vous pouvez alors utiliser exactement les mêmes modèles sur le client et le serveur. Cependant, vous n'avez pas vraiment besoin de sans logique, juste un qui a son propre «langage». Je suis d'accord avec les gens qui se plaignent que la moustache limite inutilement. Merci, mais je suis un grand garçon et je peux garder mes modèles propres sans votre aide.

Une autre option consiste simplement à trouver une syntaxe de modèle qui utilise un langage pris en charge à la fois sur le client et le serveur, à savoir javascript sur le serveur en utilisant node.js ou vous pouvez utiliser un interpréteur js et json via quelque chose comme therubyracer.

Ensuite, vous pouvez utiliser quelque chose comme haml.js qui est beaucoup plus propre que n'importe lequel des exemples fournis jusqu'à présent et fonctionne très bien.

eagspoo
la source
Je suis complètement d'accord. Après quelques lectures, je suis arrivé à la conclusion que la possibilité de créer un modèle dans JS à la fois du côté client et du côté serveur répond mieux à mes besoins qu'un tas de langages de
création de
4

En une phrase: sans logique signifie que le moteur de modèle lui-même est moins complexe et a donc une empreinte plus petite et qu'il y a moins de façons de se comporter de manière inattendue.

Kernel James
la source
3

Même si la question est ancienne et répondue, j'aimerais ajouter mes 2 ¢ (ce qui peut sembler une diatribe, mais ce n'est pas le cas, il s'agit de limitations et de quand elles deviennent inacceptables).

Le but d'un modèle est de rendre quelque chose, pas d'exécuter une logique métier. Maintenant, il y a une ligne mince entre ne pas pouvoir faire ce que vous devez faire dans un modèle et avoir une «logique métier» en eux. Même si j'étais vraiment positif envers Moustache et que j'essayais de l'utiliser, j'ai fini par ne pas pouvoir faire ce dont j'avais besoin dans des cas assez simples.

Le «massage» des données (pour reprendre les mots de la réponse acceptée) peut devenir un réel problème - même les chemins simples ne sont pas pris en charge (ce que Handlebars.js adresse). Si j'ai des données de vue et que j'ai besoin de les modifier chaque fois que je veux rendre quelque chose parce que mon moteur de modèle est trop limitant, cela n'est finalement pas utile. Et cela vainc une partie de l'indépendance de la plateforme que la moustache revendique pour elle-même; Je dois dupliquer la logique du massage partout.

Cela dit, après une certaine frustration et après avoir essayé d'autres moteurs de modèles, nous avons fini par créer le nôtre (... encore un autre ...), qui utilise une syntaxe inspirée des modèles .NET Razor. Il est analysé et compilé sur le serveur et génère une fonction JS simple et autonome (en fait comme module RequireJS) qui peut être appelée pour "exécuter" le modèle, renvoyant une chaîne comme résultat. L'exemple donné par brad ressemblerait à ceci lors de l'utilisation de notre moteur (que je trouve personnellement bien supérieur en termes de facilité de lecture par rapport à Moustache et Underscore):

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

Une autre limitation sans logique nous a frappé lors de l'appel de partiels avec Moustache. Bien que les partiels soient pris en charge par Moustache, il n'est pas possible de personnaliser les données à transmettre en premier. Donc, au lieu de pouvoir créer un modèle modulaire et réutiliser de petits blocs, je finirai par créer des modèles avec du code répété.

Nous avons résolu cela en implémentant un langage de requête inspiré de XPath, que nous avons appelé JPath. Fondamentalement, au lieu d'utiliser / pour parcourir les enfants, nous utilisons des points, et non seulement les chaînes, les nombres et les littéraux booléens sont pris en charge, mais également les objets et les tableaux (tout comme JSON). Le langage est sans effet secondaire (ce qui est indispensable pour la création de modèles) mais permet de «masser» les données selon les besoins en créant de nouveaux objets littéraux.

Disons que nous voulons rendre une table "grille de données" avec des en-têtes personnalisables et des liens vers des actions sur les lignes, et plus tard ajouter dynamiquement des lignes en utilisant jQuery. Les lignes doivent donc être partielles si je ne veux pas dupliquer le code. Et c'est là que le problème commence si certaines informations supplémentaires telles que les colonnes à rendre font partie du modèle de vue, et tout de même pour ces actions sur chaque ligne. Voici un code de travail réel utilisant notre modèle et notre moteur de requête:

Modèle de tableau:

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

Modèle de ligne:

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

Appel à partir du code JS:

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

Il ne contient aucune logique métier, mais il est réutilisable et configurable, et il est également sans effets secondaires.

Lucero
la source
13
Honnêtement, je ne vois pas l'intérêt de cette réponse, elle ne répond pas du tout à la question. Vous dites qu'il y a des limites sans vraiment décrire ce qu'elles sont ou comment elles se produisent. Enfin, vous vous lancez dans une discussion sur votre propre système qui n'est accessible à personne d'autre, en réalité cela pourrait être nul et pourrait finir un jour sur thedailywtf mais nous ne le saurons jamais. Ouvrez-le, créez un lien et laissez-nous décider!
mattmanser
1
@mattmanser, j'écris sur les limitations qui ont conduit à ne pas utiliser Moustache (et Handlebars): support manquant pour les chemins, les prédicats, les variables, la transformation des données pour appeler les partiels. Tout cela était important pour nous. Nous ouvrirons probablement le code un jour, mais comme il s'agit d'une solution côté serveur (ou à la compilation si vous le souhaitez) qui compile les modèles en code JS, elle n'aura pas le même grand public que Moustache. Si vous souhaitez entrer en contact, n'hésitez pas à me contacter - je suis également l'auteur de bsn GoldParser sur le code Google (où vous pouvez trouver facilement mon email dans le fichier readme).
Lucero
J'aime l'idée de votre rasoir comme moteur ... est-ce open source?
Cracker
@Cracker, non, ce n'est pas (encore) - le "problème" avec cela est qu'actuellement, les modèles sont compilés en code JS sur le serveur exécutant ASP.NET MVC, et donc le public cible n'est pas aussi grand qu'avec d'autres moteurs de modèles . En plus de cela, il fait partie d'une plus grande bibliothèque que nous devons d'abord démonter pour l'open sourcing.
Lucero
1
@Esailija Il permet de spécifier dynamiquement les noms de propriétés à prendre à partir de l' rowobjet, au lieu d'utiliser des noms statiques. Par exemple, si $col.property == 'Something'cela donnerait le contenu de row.Something.
Lucero
2

Voici 3 façons de rendre une liste, avec le nombre de caractères. Tous, sauf le premier et le plus court, sont dans des langages de création de modèles sans logique.

CoffeeScript (avec DSL de constructeur de café réactif ) - 37 caractères

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

Knockout - 100 caractères

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

Guidon / Moustache - 66 caractères

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

Soulignement - 87 caractères

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

La promesse de modèles sans logique était, je suppose, que les personnes ayant des compétences plus larges seraient capables de gérer des modèles sans logique sans se tirer une balle dans le pied. Cependant, ce que vous voyez dans les exemples ci-dessus, c'est que lorsque vous ajoutez un langage de logique minimale au balisage basé sur une chaîne, le résultat est plus complexe, pas moins. De plus, vous avez l'air de faire du PHP à l'ancienne.

De toute évidence, je ne m'oppose pas à ce que la "logique métier" (calcul extensif) ne soit pas utilisée dans les modèles. Mais je pense qu'en leur donnant un pseudo-langage pour la logique d'affichage au lieu d'un langage de première classe, le prix est payé. Pas seulement plus à taper, mais un mélange odieux de changement de contexte que quelqu'un a besoin de lire.

En conclusion, je ne vois pas la logique des modèles sans logique, donc je dirais que leur avantage est nul pour moi, mais je respecte le fait que beaucoup dans la communauté le voient différemment :)

Dean Radcliffe
la source
@brad, que pensez-vous de cette comparaison?
Dean Radcliffe
2

Les principaux avantages de l'utilisation de modèles sans logique sont:

  • Applique strictement la séparation modèle-vue , voir cet article pour plus de détails (fortement recommandé)
  • Très facile à comprendre et à utiliser , car aucune logique de programmation (et aucune connaissance!) N'est nécessaire et la syntaxe est minimale
  • (notamment Moustache) hautement portable et indépendant du langage, peut être utilisé sans modification dans presque tous les environnements de programmation
rmuller
la source
grande réponse concise!
MrWatson le
1

Je suis d'accord avec Brad: le underscorestyle est plus facile à comprendre. Mais je dois admettre que le sucre syntaxique peut ne pas plaire à tout le monde. Si _.eachc'est quelque peu déroutant, vous pouvez utiliser une forboucle traditionnelle .

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

C'est toujours bien si vous pouvez revenir à des constructions standard telles que forou if. Utilisez simplement <% if() %>ou <% for() %>while Mustacheutilisez un peu de néologisme pour if-then-else(et déroutant si vous n'avez pas lu la documentation):

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

Le moteur de modèles est idéal lorsque vous pouvez réaliser facilement des modèles imbriqués ( underscorestyle):

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

Fondamentalement, vous passez votre tmpl interne comme une propriété de votre contexte. Et appelez-le en conséquence. Sucré :)

En passant, si le seul élément qui vous intéresse est le moteur de modèle, utilisez l'implémentation de modèle autonome. Ce n'est que 900 caractères une fois minifié (4 longues lignes):

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

Roland
la source