Cela peut être fait par des assistants.
Regardez sur ceci : http://kan.so/packages/details/handlebars-helpers
Il existe un assistant ifequal qui permet de comparer deux valeurs.
Une solution similaire peut être utilisée pour vos besoins.

J'avais peur de ça.
Je sais que quelque chose comme ça peut être fait avec des assistants... Mais, je veux dire, comparer des trucs est tellement basique qu'il devrait être dans le package par défaut.

S'il devait être inclus dans le package, ce serait de toute façon une aide.

@thany http://doginthehat.com.au/2012/02/comparison-block-helper-for-handlebars-templates/

@andriijas tout à fait raison, ce serait en effet une aide ;) Ou pas, car un if-block est si élémentaire.
Merci pour le lien. C'est utile, mais j'ai hâte d'écrire un "helper" qui écrase l'original if, pour en faire un _proper_ if. Je suis sûr que c'est possible. Tout moteur de template qui se respecte a besoin d'une mise en forme conditionnelle appropriée. Les guidons ne devraient pas faire exception.

Vous devez surmonter le fait que tout ce qui applique la logique métier aux modèles dans le guidon est une aide.

Tous les éléments intégrés à chacun, if etc sont définis via registerHelper. Vérifier:
https://github.com/wycats/handlebars.js/blob/master/lib/handlebars/base.js

Il n'y a donc rien de "mauvais" à utiliser des assistants. Handlebars est plus ou moins juste un compilateur de modèles de moustache et pour obtenir cette logique métier supplémentaire, ils utilisent des assistants. si vous pensez que vous avez juste une mauvaise expérience de l'utilisation du mot "aides", peut-être à partir de rails ou de quelque chose.

Je n'ai jamais dit qu'il n'y avait rien de mal avec les "helpers". C'est juste qu'une instruction if appropriée n'est pas censée être une extension à mon avis. Un assistant (encore une fois, à mon avis) est quelque chose de spécifique à un CMS ou quelque chose. Un assistant est quelque chose qui effectue une opération ou une condition spéciale. Quelque chose qui n'est pas pour tout le monde. Autrement dit, s'il est défini en dehors de la bibliothèque principale. Un peu comme jQuery-plugins peut-être : les choses les plus élémentaires sont intégrées, les choses qui vous permettent de démarrer. Mais les choses qui ne sont pas pour tout le monde sont définies en dehors de la bibliothèque principale (c'est-à-dire dans les plugins). En termes jQuery, une simple fonction de filtrage ne serait pas un plugin.

Une instruction if (à mon avis) ne s'applique pas à ce paradigme de plugin. C'est élémentaire, c'est l'un des principes les plus basiques de la programmation et des moteurs de templates...

Un suivi rapide donc. Voici ce que j'ai pour l'instant :

Handlebars.registerHelper("when", function(lvalue, operation, rvalue, options) {
  console.log(arguments);
});

En utilisant ceci dans mon modèle comme {{#when riskfactor eq 0}}...{{/when}} j'obtiens dans ma console un tableau de [6, undefined, 0, function()] . Le dernier que je reçois. C'est ce que je dois appeler pour traiter le contenu de ce when-block. Les trois premiers... enfin pas tant que ça. Le « 6 » est en fait la valeur du « facteur de risque ». D'accord, je peux y aller. L'indéfini me dépasse. Je pense que Handlebars essaie de l'évaluer sur l'objet d'entrée, mais cela ne fonctionnera pas. Je veux obtenir des choses qui sont en fait _dans_ le modèle, car des valeurs comme celles-ci n'ont rien à voir avec mon objet.

Je m'attendais à quelque chose comme ["riskfactor", "eq", "0", function()] . Ce n'est qu'alors que ma fonction peut continuer et traiter cela. Comment vais-je faire avec « undefined » ?

Je pense que la philosophie de Handlebars (et d'autres modèles "sans logique") est que le contexte qui arrive pour le modèle doit déjà être entièrement traité. Si les structures de données internes de votre application ne correspondent pas parfaitement à ce qui serait approprié pour un modèle (ce qui sera le cas presque à chaque fois), vous devez alors insérer une étape avant de rendre le modèle qui construit le contexte du modèle à partir des données internes de votre application structure.

Je crois que c'est l'intention quand les gens parlent de « séparer la logique de la présentation ». Considérez les guidons comme le composant de vue d'un système MVC. Votre modèle existe déjà ; tout ce que vous devez écrire maintenant est le contrôleur (dans ce cas, il s'agit d'un ensemble de liaisons unidirectionnelles du modèle à la vue).

Pour répondre à votre question la plus récente, vous souhaitez utiliser ceci :

 {{#when "riskfactor" "eq" 0}}...{{/when}}

Les expressions de guidon sont soit des noms de variables, soit des chaînes. S'il s'agit d'un nom de variable, vous obtiendrez la valeur de la variable lors de la recherche dans le contexte actuel, pas le nom.

Ceci est en dehors du domaine des guidons, comme certains l'ont souligné.

Non.
N'IMPORTE QUEL système de modèles peut faire un simple bloc comparatif if-else, et les guidons ne le peuvent pas. Cela rend Handlebars soit ridiculement incomplet, ses fabricants incompétents (ce qui est peu probable cependant), ou un système avec une perspective obscure des tâches d'un système de modèles.

N'UTILISEZ PAS UN MOTEUR DE MODÈLE SANS LOGIQUE ALORS. KTHXBA !

J'ai compris. Toodles.

@thany , @andriijas était probablement un peu dur, mais il a raison. Le guidon est conçu pour être sans logique. Vous pouvez certainement fabriquer un vélo avec un moteur, mais de nombreuses entreprises sont heureuses de ne fabriquer que des vélos sans moteur. De même, vous pouvez créer un système de modèles avec plus de logique, mais ce n'est pas quelque chose que Handlebars essaie de faire. Désolé ce n'est pas ce que vous cherchiez.

Je dois me ranger du côté de @thany sur l' if . Nous devrions pouvoir lui transmettre n'importe quel prédicat. Ne pas pouvoir vraiment limiter son utilité. Je comprends la philosophie derrière les modèles sans logique mais une implémentation dogmatique n'est pas vraiment pragmatique (et donc l'existence des helpers, non ?). Je dirais que cela ressemble plus à l'ajout d'un rapport de démultiplication variable par le fabricant de vélos, ce qui serait tout à fait raisonnable.

BTW, si vous voulez faire rage contre la machine et faire cela, vous pouvez créer un assistant qui prend le prédicat sous forme de chaîne, puis l'évaluer (et le rendre deux fois hérétique :smiling_imp:):

Handlebars.registerHelper('when', function (predicate, options) {
    var declarations = '';
    for (var field in this) declarations += field + ' = this.' + field + ',';
    if (eval(declarations + predicate)) { return options.fn(this); }
});

{{#when 'admin || superUser'}}
    crazy go nuts
{{/when}}

@thany le regarde du point de vue des meilleures pratiques, votre back-end doit servir les données avec toute la logique déjà intégrées http://handlebarsjs.com/#conditionals

Sérieusement, TOUTES (ou même 95%) les décisions prises ne sont pas orientées backend. Par exemple, pour déterminer quel nom de classe afficher, il est tout à fait raisonnable de prendre cette décision dans le modèle. Quelque chose comme ça est lié à 100% au frontend/modèle. Le backend se moque bien du nom de classe rendu. Ou qu'en est-il des mots singulier/pluriel ? C'est une autre chose qui ne peut pas être faite avec le bloc if.

À mon avis, le backend est chargé de fournir des données, et des données UNIQUEMENT, lorsque vous travaillez avec des modèles riches comme celui-ci. Si le backend doit donner à l'analyseur de modèle des variables prêtes à l'emploi pour chaque situation sur laquelle le modèle pourrait éventuellement prendre une décision (compte tenu d'une certaine flexibilité ici), elles seraient ridiculement compliquées juste à cause de la quantité de variables, sans parler du backend qui les fait.

Vous pouvez aussi bien mettre du HTML dans le backend si chaque décision dont un modèle a besoin nécessite une autre modification dans le backend. Cela enlève juste une grande partie de l'objectif des modèles. Les décisions liées au backend sont à un niveau complètement différent. Un bloc if n'est pas nécessairement logique. Il s'agit simplement de décider quoi/comment rendre.

Je ne peux pas croire que ce problème nécessite une si longue discussion, est-ce qu'un bloc if approprié est vraiment trop demander? :(

Je ne vais pas argumenter pour ni contre la mise en œuvre d'un assistant de comparaison de base, mais c'est le cas très réel où je ne pense pas que j'aurais pu rendre le modèle sans utiliser un assistant ou changer la structure des données :

    <select name="datatype">
      <option{{#ifeq type 'foo'}} selected="selected"{{/ifeq}}>foo</option>
      <option{{#ifeq type 'bar'}} selected="selected"{{/ifeq}}>bar</option>
      <option{{#ifeq type 'vaz'}} selected="selected"{{/ifeq}}>baz</option>
    </select>

Mais là encore, l'assistant que j'ai écrit était composé de trois lignes de code :

    Handlebars.registerHelper('ifeq', function (a, b, options) {
      if (a == b) { return options.fn(this); }
    });

je suis d'accord avec @thany , je ne pense pas non plus que ce soit quelque chose qui devrait être en dehors du modèle/de la vue.

pourquoi exactement un modèle ne peut-il pas avoir de logique? et comment les guidons assurent-ils une séparation de la logique et de la présentation ? il a toujours une instruction if , n'est-ce pas ? Êtes-vous en train de dire qu'une déclaration if qui teste simplement l'existence et/ou la « fausseté » n'est en rien différente d'une déclaration if qui vérifie l'(in)égalité ou toute autre condition ?

la seule différence - réelle - est donc que, contrairement à d'autres bibliothèques de modèles, le guidon a une implémentation très pauvre/incomplète de ladite logique sous prétexte d'être " sans logique ". Je suis désolé, mais c'est complètement absurde. si vous souhaitez supprimer la logique, vous devez supprimer complètement l'instruction if . vous ne le ferez pas, car en fin de compte, un modèle a besoin de logique pour la ou les mêmes raisons pour lesquelles le guidon a toujours une instruction if .

ainsi, l'énoncé « séparer la logique de la présentation ». est fallacieux, pas seulement pour les raisons ci-dessus, mais aussi parce que vous ne supprimez pas la "logique" du modèle, vous le déplacez simplement vers une autre partie du modèle - c'est-à-dire l'assistant - et vous obtiendrez peut-être une réutilisation du code - ce qui serait une bonne chose - et peut-être que vous ne le faites pas, auquel cas vous pouvez obtenir un certain nombre d'assistants effectuant presque/exactement la même chose que les autres assistants, en raison d'une différence mineure qui aurait été meilleure en fournissant une implémentation correcte de if . en quoi est-ce une bonne décision de conception ?

J'ai toujours du mal à comprendre pourquoi, si une certaine "logique" est intrinsèquement liée à une vue spécifique et n'a aucune importance, signification et/ou utilité pour autre chose que la vue elle-même, quel est exactement le problème. cela ressemble simplement à de l'extrémisme / extrémisme mvc pour moi.

@andriijas si je pouvais utiliser une bibliothèque de modèles différente, je le ferais, malheureusement, la décision ne

Quelqu'un a-t-il réellement regardé comment le courant if est mis en œuvre? (il y a aussi à moins ce qui est sympa)

Maintenant que vous avez vu comment le if est actuellement implémenté, il est peut-être plus logique pour vous que les guidons aient une valeur par défaut simple et élégante qui satisfasse la plupart des gens.

Regardez ici à quel point il est facile d'étendre

https://github.com/elving/swag

https://github.com/elving/swag/blob/master/src/swag.comparisons.coffee

Acceptez que tous vos projets open sources ne fournissent pas tout ce dont vous avez besoin pour cuisiner votre bacon, juste les bases.

@andriijas oui, unless est juste un if avec le résultat inversé. Je ne vois pas en quoi cela compense quoi que ce soit. merci pour le lien de repo helpers, j'ai déjà écrit un helper, encore une fois, je ne vois pas en quoi cela compense quoi que ce soit.

Le guidon fait un peu plus de 10ko (minzippé) et le swag est un peu moins de 3ko ​​(minzippé). Vous ajoutez donc une bibliothèque de modèles de 10 Ko à votre base de code et vous avez besoin de 3 Ko supplémentaires juste pour pouvoir ajouter de la logique à vos modèles. logique que vous et plusieurs autres dites que vous ne devriez pas avoir dans vos modèles de toute façon ?

cela ne répond à aucune de mes questions et en fait, cela ne sert qu'à prouver qu'il est absurde d'interdire les tests conditionnels autres que l'existence/la fausseté dans votre bloc d'instructions if .

@andriijas Je regarde /lib/handlebars/base.js#L97 , mais je ne suis pas vraiment sûr de ce que vous voulez dire. Il semble qu'il existe une forme d'utilisation alternative, mais la documentation ne le précise pas. Voudriez-vous expliquer?

@constantology, certaines personnes pourraient avoir besoin de 3 Ko supplémentaires, vous et les autres gars de ce fil par exemple. Le reste des 3500 qui ont joué ce dépôt sur github ne sont pas susceptibles de se plaindre, car ils ont résolu leurs besoins logiques en ajoutant des assistants ou en le faisant avant de rendre les modèles.

@piksel ce que vous regardez, c'est le fait que le if intégré n'est qu'une aide comme n'importe quel "add-on" avec lequel beaucoup semblent avoir un problème, pensant que les aides sont plus lentes ou quelque chose du genre.

Il n'y a rien de mal à utiliser des assistants dans votre projet. Dans un projet, j'utilise certains des assistants swag, copiés dans mon propre fichier view_helper, donc c'est encore moins de 3k.

Dans un projet de backbone, j'ai une méthode getTemplateData sur mes vues, où je résume une logique complexe à des choses plus simples qui rendent les modèles plus propres et plus faciles à suivre, ah et aussi, il est plus facile de tester un javascript simple que les modèles de guidon.

@andriijas qui ne répond toujours à aucune de mes questions...

à ce stade, je ne ferais que répéter ce que j'ai déjà dit, donc si vous pensez que vous pouvez réellement fournir une réponse raisonnable à tout ou partie des questions que j'ai déjà posées, alors je serais très heureux d'entendre ce que vous devez dire. :)

ps le nombre de personnes qui ont joué le rôle du repo et/ou utilisent la bibliothèque n'est pas nécessairement une indication de la qualité d'une bibliothèque. il y a plus d'utilisateurs Windows que mac/linux combinés et, selon le site de statistiques de navigateur que vous consultez, il y a encore plus de personnes utilisant Internet Explorer 6, 7 et 8 combinés qu'un navigateur plus moderne. cela ne fait pas de Windows un meilleur système d'exploitation que osx ou linux et cela ne rend pas les anciennes versions d'Internet Explorer meilleures que les normes modernes et les navigateurs compatibles.

Toute cette discussion est stupide pour moi. Un assistant if est là, C'EST LOGIQUE. Donc, tout l'argument sans logique est un homme de paille total. C'est comme si une voiture avait des vitres qui ne feraient que s'abaisser et que les gens se plaignaient et voulaient qu'elles s'enroulent aussi. Et le constructeur a dit qu'il n'allait pas le changer parce que ces voitures suivaient une philosophie stricte de ne pas avoir de vitres à commande mécanique... Soit vous le soutenez, soit vous ne le faites pas. Une mise en œuvre à moitié idiote ne devrait pas être justifiée par un argument d'homme de paille.

Je suis tout à fait d'accord et je comprends qu'il n'y ait pas de logique métier dans les modèles. Mais à moins que vous ne fassiez des modèles extrêmement triviaux, vous aurez une logique de vue là-bas. Handlebars le reconnaît évidemment puisque l'assistant if existe. Travailler autour d'un assistant if aux ischio-jambiers en ajoutant un tas de logique de vue dans votre code n'est pas la réponse comme l' a souligné

@mikeobrien oui, je l'ai déjà mentionné dans un commentaire précédent . c'était l'une des nombreuses questions qui sont restées sans réponse.

Je suis tout à fait d'accord et je comprends qu'il n'y ait pas de logique métier dans les modèles. Mais à moins que vous ne fassiez des modèles extrêmement triviaux, vous aurez une logique de vue là-bas.

Bien placé. :^)

@constantology doh, désolé, je suppose que j'aurais dû mieux lire les commentaires précédents. :/

Je suis d'accord avec @constantology

FWIW Je trouve que Handlebars est une bibliothèque de modèles vraiment élégante et bien écrite.

Je comprends très bien le concept de blocs et d'assistants, cependant, je ne pense pas que créer un assistant pour faire quelque chose de petit - qui pourrait être géré plus élégamment en le prenant en charge dans la bibliothèque principale - signifie une séparation claire de la logique et de la présentation. CSS ajoute la prise en charge des instructions conditionnelles et une partie de cela peut déjà être réalisée avec des requêtes multimédias, donc la logique dans un langage purement de présentation n'est pas nécessairement un gros bobo, s'il s'agit simplement de "logique de vue" comme l'a dit @mikeobrien .

Je pense que cette seule limitation - le manque de vérifications conditionnelles dans les blocs if / unless - rend très difficile la création de modèles élégants et encapsulés.

En outre, je suis également d'accord avec le fait d'avoir une méthode pour prétraiter les données avant de les analyser via un modèle, cependant, uniquement pour des modifications simples, et non pour reformater l'intégralité de la structure de données afin de la plier à la volonté de n'importe quelle bibliothèque. Pourquoi?

1. cela pourrait potentiellement affecter les performances globales de l'analyse si vous devez prendre une structure de données complexe et créer quelque chose de plus plat.
2. basé sur 1 , il peut potentiellement rendre votre code de vue plus fragile - et plus difficile à refactoriser - si des modifications sont apportées au schéma d'origine.
3. cela pourrait également rendre la liaison de données bidirectionnelle plus délicate car vous ne mappez plus la structure de données d'origine à la vue, augmentant ainsi la quantité de code dont vous pourriez avoir besoin pour suivre les modifications.

Ce ne sont que des idées reçues, je n'ai fait aucune recherche quantifiable pour étayer tout cela, mais c'est matière à réflexion. :^)

pour la question d'origine, un if helper avec comparaison serait la mauvaise chose. c'est un scénario courant et des aides comme :
{{#ifzero count}}Aucun résultat{{/ifzero}}
{{#ifsingular count}}1 résultat{{/ifsingular}}
{{#ifplural count}}{{count}} résultats{{/ifplural}}
serait plus utile et se traduirait par ce qu'il veut vraiment faire. la syntaxe if actuelle est utile pour (ne pas) afficher les valeurs vides. un scénario très courant aussi. si quelqu'un a vraiment besoin d'un si avec comparaison, il est très probable qu'il s'agisse d'une logique métier et il ne devrait pas le faire dans le modèle.

Cela le ferait en effet.
Cependant, je pense toujours qu'il n'appartient pas à un moteur de forcer les développeurs dans un certain coin, que ce soit _en principe_ un bon coin, ou non. Je pense que cela devrait appartenir au développeur qui est la logique métier et qui est la logique du modèle.

C'est-à-dire, à moins que la limitation de ne pas pouvoir faire de comparaisons soit une limitation purement technique qui en a en quelque sorte fait un paradigme. Cela signifie seulement qu'une telle fonctionnalité ne pourrait jamais être ajoutée en cas de besoin. J'espère que ce n'est pas ce qui s'est passé.

Merci de tester. Essai. Vous ne voulez pas mettre de comparaisons dans les modèles car vous ne pouvez pas tester cette logique facilement. Il est beaucoup plus simple de créer des valeurs booléennes simples via un formateur de données pour votre modèle et de le tester, que de se connecter à quelque chose comme le sélénium et de le tester là-bas.

Ce n'est pas juste de la théorie, ce n'est pas juste « en principe ». Ce serait probablement des conneries sur la dette technique du monde réel de mettre même des comparaisons dans les modèles et de ne pas tester cette logique. N'écrivez pas et n'utilisez pas ces aides. Je n'ai pas encore utilisé d'assistant pour le guidon. Cependant, si vous avez utilisé un assistant, vous pouvez l'espionner et tester pour vous assurer que la chose a fonctionné, donc c'est mieux que des comparaisons intégrées dans les modèles.

Il existe de nombreux systèmes de modèles sans logique qui n'offrent pas de comparaisons. Par exemple, dans les langages fortement typés comme go, que signifie l'égalité ? Il n'y a pas de comparaisons dans les modèles Go. Il existe des implémentations de moustache et de guidon dans toutes les langues et elles sont identiques.

Supprimer la logique comme les comparaisons des modèles ne vous rend pas la vie plus difficile, cela la rend plus facile. La dette technique n'est pas une blague, elle peut ruiner des produits et même des entreprises.

Allez.
Les comparaisons ne sont pas si difficiles. Ce n'est pas sorcier (ou chirurgie du cerveau).

Dans les micro-modèles très simples, vous n'avez pas besoin de logique, mais si cela devient plus compliqué, vous aurez besoin de logique dans les modèles. Il existe une « logique métier » ainsi qu'une « logique de modèle ». Déterminer quoi faire quand il n'y a qu'un seul élément de quelque chose, ou deux, ou dix. Pagination, par exemple. Diviseurs. Des textes simples "moins de 50%" et "plus de 50%", et je pourrais continuer.

Le fait que les autres moteurs de modèles n'aient pas de logique non plus ne signifie pas que vous devez les suivre aveuglément. Ils ont tort aussi, à mon avis.

Le fait est qu'à un moment donné, vous allez avoir une sorte de logique dont vous n'avez tout simplement pas besoin ou que vous ne voulez pas dans la logique métier, simplement parce que ce n'est pas de la logique métier. Je ne peux pas dire à mes collègues développeurs d'avoir une valeur booléenne dans, pour chaque type de comparaison imaginable dont tout modèle actuel ou futur pourrait avoir besoin.

« ça peut ruiner des produits et même des entreprises » ? Sérieusement?
Une fonctionnalité incorrecte peut aussi.

Quel est le problème avec l'expédition de ce dont la plupart des gens ont besoin et vous ajoutez une aide
pour ce dont tu as besoin ? Tout le monde y gagne. Ce n'est pas si difficile, pas comme une fusée
science.

Si c'est sorcier : https://github.com/elving/swag

Le samedi 18 mai 2013, thany a écrit :

Allez.
Les comparaisons ne sont pas si difficiles. Ce n'est pas sorcier (ou chirurgie du cerveau).

Dans des micro-modèles très simples, vous n'avez pas besoin de logique, mais s'il y en a
plus compliqué, vous aurez besoin de logique dans les modèles. Il y a un tel
chose comme « logique métier » ainsi que « logique de modèle ». Déterminer quoi
faire quand il n'y a qu'un seul élément de quelque chose, ou deux, ou dix. Paging, pour
Exemple. Diviseurs. Des textes simples "moins de 50%" et "plus de 50%", et je pourrais continuer.

Le fait que les autres moteurs de modèles n'aient pas de logique non plus,
ne signifie pas que vous devez les suivre aveuglément. Ils se trompent aussi dans mon
avis.

Le fait est qu'à un moment donné, vous allez avoir une sorte de logique que vous venez de
n'ont pas besoin ou ne veulent pas dans la logique métier, simplement parce que ce n'est pas une affaire
logique. Je ne peux pas transmettre à mes collègues développeurs une valeur booléenne
dans, pour chaque type imaginable de comparaison que toute comparaison actuelle ou future
modèle pourrait jamais avoir besoin.

« ça peut ruiner des produits et même des entreprises » ? Sérieusement?
Une fonctionnalité incorrecte peut aussi.

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/wycats/handlebars.js/issues/206#issuecomment -18104713
.

La plupart des gens qui ne l'utilisent pas peuvent être dus au problème qui est décrit ici : aucune logique. Alors bien sûr, la plupart des gens qui l'utilisent activement en seront plus ou moins satisfaits.

@thany je te sens et je suis d'accord avec toi.

Je pense que les gens derrière le guidon ne veulent pas abandonner celui-ci, mais bon, ce que je vais vous dire, c'est une nouvelle incroyable :
Vous pouvez _fork _ le projet, ajouter le patch et utiliser votre propre fork.
En raison de la magie de git, il devrait être assez facile de suivre les nouvelles versions en seulement git pull ing.

Et attendez, ça va mieux.

Si cela s'avère être un grand besoin et que c'est globalement mieux, peut-être que les gens commenceront à utiliser votre fourche ou encore mieux mieux, les gars derrière le guidon fusionneront votre fourche avec origin/master :dancer:

en avoir un bon ;D

Si je m'accordais le temps, bien sûr !

Je suis tout à fait d'accord avec @constantology. Son insensé a un modèle sans logique. Et si vous vouliez avoir un modèle sans logique pourquoi vous y mettez la déclaration : "si" ce qui représente la logique comme danger de couleur rouge... Cela n'a pas de sens. Je pense que la logique de comparaison de base est nécessaire comme le sel dans la soupe. @mikeobrien :"Une implémentation à moitié

Il y a quelque chose à dire pour les modèles sans logique. Cependant, je pense que le problème est que tout le monde ici confond la logique métier avec la logique de vue. La logique métier n'a pas sa place dans les modèles. Période. La logique de vue, cependant, est une tout autre affaire. Je pense que Handlebars s'en rend compte, c'est pourquoi ils ont ajouté le if/else en premier lieu, ils sont juste devenus un peu confus en cours de route.

J'ai besoin de savoir si mon tableau de données contient un élément ou plusieurs, et en fonction de cela, je veux les joindre avec des virgules ou ajouter un pluriel à un mot. Avec le bloc if actuel, je ne peux pas le faire.

C'est pourquoi j'ai fait cette pull request : https://github.com/wycats/handlebars.js/pull/566 et jsfiddle d'accompagnement : http://jsfiddle.net/YsteK/

Cette requête d'extraction fournit un nouvel assistant : ifTest, qui prend une expression javascript qui s'évalue exactement comme javascript le ferait étant donné le contexte. Prendre plaisir.

Honnêtement, c'est une fonctionnalité tellement basique que je pense que si vous voulez vous en tenir à cet état d'esprit de ne pas avoir de logique intégrée dans le cadre (ce qui me semble complètement illogique !), vous devez reconsidérer l'utilisation de termes logiques tels que "si" .

Je me retrouve à ajouter ceci à beaucoup de mes projets simplement parce que c'est très utile pour comparer des choses telles que "0" et "1" à d'autres valeurs booléennes :

Handlebars.registerHelper('ifCond', fonction(v1, v2, options) {
si(v1 === v2) {
renvoie options.fn(ceci);
}
retourner options.inverse(ceci);
});

Je pense qu'il est tout à fait juste de faire fonctionner la fonctionnalité "if" existante comme elle le fait, mais faites une faveur à la langue anglaise et choisissez un autre mot (ou faites-lui faire ce que les gens attendent de lui). Cela ressemble à une véritable perversion du terme "si" lorsqu'il ne se comporte tout simplement pas comme une véritable déclaration if dans un autre contexte.

J'aimerais ajouter un autre vote pour supprimer complètement if ou autoriser if à accepter certains arguments de comparaison de base, par exemple eq , ne , gt , etc. Vous vous retrouveriez avec {{#if arg1 eq arg2}} . Bien sûr, supprimer complètement if aurait plus de sens pour votre philosophie "pas de logique dans les modèles" (en ce moment, c'est plutôt "pas de logique dans les modèles _la plupart du temps_ mais _parfois_ ça va").

Sans aide, je finis par faire des trucs comme ça tout le temps :

<select>
    <option value='ak' {{#if ak_selected}}selected{{/if}}>AK</option>
    <option value='al' {{#if al_selected}}selected{{/if}}>AL</option>
    <option value='ar' {{#if ar_selected}}selected{{/if}}>AR</option>
    <option value='az' {{#if az_selected}}selected{{/if}}>AZ</option>
    <option value='ca' {{#if ca_selected}}selected{{/if}}>CA</option>
    ....
</select>

Ce qui semble un peu idiot d'ajouter toutes ces propriétés supplémentaires à un objet.

webgovernor - Découvrez ceci : http://jsfiddle.net/YsteK/

C'est une aide qui permet cette fonctionnalité. Il faut une expression javascript qui évalue exactement comme javascript le ferait étant donné le contexte. Prendre plaisir.

Merci tniswong, c'est très similaire à mon assistant. J'ai résolu le problème, je voulais juste souligner l'hypocrisie du dogme "sans logique" du guidon.

Aucun problème. Je suis là avec toi. J'adore les guidons, mais c'est assez inutile sans cette aide.

J'ai soumis cette aide en tant que pull-request mais elle a été rejetée. J'ai donc soumis une autre pull-request qui a supprimé le bloc if. Egalement rejeté. /soupir

Hahaha. Github a besoin d'un bouton de vote positif.

Il a été rejeté ? -_-

L'obstination de la religion sans logique de Handlebars est vraiment ahurissante.

566 et #568

Il a mentionné qu'il pourrait l'ajouter au fichier README, mais je ne retiens pas mon souffle.

+1 à ça ! Argghhh !

FWIW, le dépôt Swag fournit des aides qui ajoutent des comparaisons, des tris et d'autres trucs astucieux. Je ne construis rien dans Handlebars sans cela.

Cela dit, je suis personnellement d'accord avec le fait de laisser Handlebars rester aussi logique que possible car il le maintient propre, extensible et maintenable. Si vous en voulez plus, contribuez à un dépôt comme _Swag_ pour des choses en dehors du cadre du projet. Si les mainteneurs de ce projet changent d'avis, il suffit d'une pull request :+1:

@aboutaaron Si vous allez faire une déclaration comme "laisser le guidon rester aussi logique que possible car il le maintient propre, extensible et maintenable", vous devriez au moins avoir la décence de :

1. fournir la preuve que le guidon ne contient aucune logique. Si vous avez lu le fil, vous verrez qu'il a déjà été prouvé que le guidon contient une logique incomplète sous la forme d'une instruction if qui vérifie uniquement la "vérité", si vous n'avez pas lu le fil, je vous suggérerais de le faire.
2. fournir la preuve que les guidons fournissant une logique incomplète sous la forme d'une déclaration if qui vérifie uniquement la "vérité", d'une certaine manière, "le maintient propre, extensible et maintenable".
   N'est-ce pas une contradiction ? Si le guidon est extensible, cela ne signifie-t-il pas qu'il serait trivial de fournir une implémentation complète des instructions conditionnelles ?
   Comment, par exemple, des guidons fournissant une instruction if complète le rendraient-ils moins propre, extensible et maintenable qu'un développeur utilisant des guidons ET du swag ?
   On pourrait soutenir que l'utilisation des aides swag rendra une base de code moins propre, extensible et maintenable puisque vous devez utiliser une aide différente pour chaque opérateur de comparaison, c'est- gt dire gte , is , isnt , lt , lte ainsi que pour chaque opérateur logique, soit and , or .
   Comment cela rend-il le code plus lisible que de faire tout cela comme on le ferait — dans une instruction if — dans n'importe quel autre langage ? Si tel était le cas, je supposerais que les langages de programmation eux-mêmes supprimeraient les instructions conditionnelles qui vérifient autre chose que la «vérité»? Je ne vois pas cela se produire.

Si par hasard vous allez utiliser l'argument éculé – et réfuté – de « mettre une logique métier dans le modèle », veuillez ne pas le faire. cela a déjà été abordé - plusieurs fois, par plusieurs personnes - dans ce fil. En même temps, si c'est quelque chose que vous considérez comme un argument valide, cela éliminerait le besoin d'utiliser la bibliothèque swag , en contradiction avec votre déclaration précédente.

En conclusion, le fait qu'il existe plusieurs bibliothèques qui cherchent à compléter l'implémentation incomplète de if dans les guidons - d'une manière ou d'une autre - montre qu'il existe un besoin pour ce type de fonctionnalité dans son coeur. Regardez le langage JavaScript lui-même, Harmony introduit de nombreuses fonctionnalités fournies par des bibliothèques tierces, des itérateurs, des modules, des générateurs, des classes, des proxys, etc. et l'API DOM a également implémenté des fonctionnalités fournies par des bibliothèques tierces, querySelector[All], CORS et il existe même une implémentation des promesses DOM dans Chrome Canary.

Il n'y a aucune preuve que "laisser le guidon rester aussi logique que possible car il le maintient propre, extensible et maintenable". Dans le même temps, d'autres et moi avons montré - dans les commentaires précédents de ce fil - qu'un peu peut aller très loin, si les guidons fournissaient une implémentation complète de if cela donnerait aux développeurs une API unifiée à faire leurs modèles plus faciles à lire et à maintenir.

@constantologie +1 Amen.

Je viens d'arriver ici après avoir essayé {{#if quelque chose > quelque chose_else}} et réalisé la vérité de cette situation. Cependant, je suis tenté d'être d'accord avec les gens du guidon sur celui-ci. J'ai utilisé du liquide pendant longtemps, et les fils de commentaires comme celui-ci conduisent inévitablement à l'ajout de fonctionnalités à moitié cuites comme les mathématiques et la concaténation de chaînes qui appartenaient vraiment au back-end.

L'objectif avec l'instruction if "sans logique" semble être : faire la partie logique sur le back-end et présenter les guidons avec la "réponse" comme une seule variable. Si la réponse est « oui », faites-le, sinon faites l'autre chose. Je ne vois pas de problème avec cela (après avoir lu les commentaires ci-dessus), et je vais corriger mon code maintenant.

Travaillant sur certaines applications Ember et je voulais jeter à mon avis. Je pense que la déclaration #if serait meilleure si elle _(éventuellement)_ acceptait un argument. Je comprends tout à fait le désir de laisser les choses logic-less , mais cela peut être assez frustrant de travailler avec parfois.

Imaginez une simple liste de questions à sélectionner ou à désélectionner. Vraiment, quelle est la différence entre ces deux blocs de logique ?

{{#if isSelected question}}
  <p>This question is selected</p>
{{else}}
  <p>This question is NOT selected</p>
{{/if}}

{{#if question.isSelected}}
  <p>This question is selected</p>
{{else}}
  <p>This question is NOT selected</p>
{{/if}}

Il y a des différences assez importantes dans la façon dont j'ai besoin d'écrire le code soutenant ces deux exemples. Ce serait vraiment bien d'avoir la possibilité de choisir non plus. Je ne vois pas vraiment non plus en quoi le premier contient plus de logique que le second.

J'ai ressenti la même chose que ce fil dit. Ensuite, j'ai trouvé ce fil.
Par conséquent, je suppose que je viens de comprendre la philosophie des guidons.
Ensuite, j'ai compris que j'avais besoin d'une collection d'aides comme Swag.

Maintenant, je n'ai plus de problème car Swag va m'aider.
Cependant, je suis devenu confus parce que l'assistant par défaut if était trop simple.
Si vous dites que Hanlebars est sans logique, je doute que Handlebars ait besoin d'aides intégrées.
S'il n'y avait pas d'aides intégrées, je pense que je pourrais comprendre plus facilement la philosophie de Handlebars.

Je n'ai peut-être pas une bonne compréhension de logic-less et business logic , je veux vous dire ce que j'ai pensé.

Je pense que vous ne pouvez tout simplement pas considérer un seul if/unless (sans conditionnel) comme de la logique, car c'est juste -dans le contexte sans logique- un moyen de représenter une donnée booléenne, comme le "{{foo}}" la syntaxe est un moyen de représenter une chaîne de données.

Je pense donc que le comportement suivant devrait être arrêté : « Si c'est sans logique, pourquoi y a-t-il une instruction if ? HA-HA, échec et mat !!! »

Changez-le ensuite en "{{#exists}}" au lieu de "{{#if}}" car cela a plus de sens.

Le 5 octobre 2013 à 10h52, call127 [email protected] a écrit :

Je pense que vous ne pouvez tout simplement pas considérer un seul if/unless (sans conditionnel) comme de la logique, car c'est juste -dans le contexte sans logique- un moyen de représenter une donnée booléenne, comme le "{{foo}}" la syntaxe est un moyen de représenter une chaîne de données.

Je pense donc que le comportement suivant devrait être arrêté : « Si c'est sans logique, pourquoi y a-t-il une instruction if ? HA-HA, échec et mat !!! »

-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

:thumbsup : pour changer {{#if}} en {{#exists}} ou {{#isTrue}}

Je suis d'accord que nous pouvons trouver un nom plus sensé. « existe » le ferait, et mes suggestions seraient « vrai » ou « on ».

Mais néanmoins, le nom « si » serait encore plus approprié pour des raisons historiques. Si l'implémentation de guidon n'est pas différente syntaxiquement de toute autre implémentation de if, elle est conforme à l'ancienne syntaxe "if ([prédicat]) [do sth]".

Ce qui est différent, c'est que le [prédicat] doit être une variable booléenne nue, cela ne peut pas être une expression. Mais ce n'est pas la limitation de 'if'. Il s'agit d'une limitation plus générique causée par le manque de prise en charge des expressions de l'interpréteur Handlebars. (Ce qui est exactement ce qui rend le guidon sans logique d'ailleurs, je pense)

Ce qui signifie que ce "si" n'est pas différent de tout autre "si".

Et essayer de changer le nom de « si » peut être considéré comme une hérésie par certains, ne dites pas que je ne vous ai pas prévenu.

Appelez cela {{#truthy}} et {{#falsey}} parce que c'est tout ce que font {{#if}} et {{#unless}} .

Aux développeurs : sortez la tête du sable. Sérieusement. Vous pouvez voir qu'il y a une demande pour une instruction if appropriée (et j'ai l'intention d'utiliser le mot « demande » assez littéralement), alors allez-y et mettez-la en œuvre, au lieu de vous plaindre de l'absence de logique. Si vous voulez que vos modèles soient sans logique, supprimez TOUTE logique, y compris {{#if}} et {{#each}} .

implémentez JUSTE une instruction if appropriée.
Les gens qui croient fermement en leur absurdité choisiront de ne pas l'utiliser. Simple. Comme. Cette.

J'ai même déjà fait le travail pour toi.

https://github.com/wycats/handlebars.js/pull/566
https://gist.github.com/tniswong/5910264

Le 5 octobre 2013 à 15 h 20, thany [email protected] a écrit :

Appelez-le {{#truthy}} et {{#falsey}} car c'est tout ce que {{#if}} et {{#unless}} font.

Aux développeurs : sortez la tête du sable. Sérieusement. Vous pouvez voir qu'il y a une demande pour une instruction if appropriée (et j'ai l'intention d'utiliser le mot « demande » assez littéralement), alors allez-y et mettez-la en œuvre, au lieu de vous plaindre de l'absence de logique. Si vous voulez que vos modèles soient sans logique, supprimez TOUTE logique, y compris {{#if}} et {{#each}}.

implémentez JUSTE une instruction if appropriée. Les gens qui croient fermement en leur absurdité choisiront de ne pas l'utiliser. Simple. Comme. Cette.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

Merci pour cela, mais la solution devrait être dans le package de base. Le terme "ifTest" est probablement uniquement dû au fait que Handlebars détourne le terme "if" avant que vous ne puissiez l'utiliser.

Une autre chose est que votre ifTest prend une chaîne et effectue l'évaluation de cette chaîne au moment de l'exécution, alors que si un bloc if approprié se trouvait dans le package de base, il pourrait être dans le modèle compilé (qui est exactement l'un des éléments forts de Handlebars points - un que je n'aime pas jeter par-dessus bord en utilisant eval() pour les si et les autres)

Vous avez 100% raison. En utilisant simplement les outils dont je disposais à l'époque.

Peu importe, ça marche.

Le 5 octobre 2013 à 15 h 41, thany [email protected] a écrit :

Merci pour cela, mais la solution devrait être dans le package de base. De plus, le terme "ifTest" est probablement uniquement dû au fait que Handlebars détourne le terme "if" avant que vous ne puissiez l'utiliser. Une autre chose est que votre ifTest prend une chaîne et effectue l'évaluation de cette chaîne au moment de l'exécution, alors que si un bloc if approprié se trouvait dans le package de base, il pourrait être dans le modèle compilé (qui est exactement l'un des éléments forts de Handlebars points - un que je n'aime pas jeter par-dessus bord en utilisant eval () pour les si et les autres)

-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

Je viens de tomber sur ce fil en cherchant une comparaison dans Handlebars. Je pense que vous devriez soit supprimer / renommer les blocs {{#if}} et {{#each}} , soit implémenter une instruction if appropriée. C'est une fonctionnalité de base pour chaque langue. Période. Si vous voulez vraiment des modèles sans logique, pourquoi n'utilisez-vous pas simplement Moustache à la place ?

Je comprends qu'il existe une opinion parmi les développeurs selon laquelle les modèles devraient être lisibles par des non-développeurs (c'est-à-dire des concepteurs). Mais A) je n'ai jamais travaillé avec un concepteur où cela posait un problème, et B) je pense que l'approche devrait être qu'une solution générique est disponible intégrée, et comme extension, vous pouvez utiliser la vérification booléenne uniquement, donc vous avez un choix. De plus, l'ajout d'aides comme {{#ifValueEqualsA}} et {{#ifValueEqualsB}} vous obligera à créer beaucoup de code passe-partout qui n'est tout simplement pas nécessaire. Je travaille dans un projet mobile pas si gros et j'ai déjà 200 lignes de code qui ajoutent juste des comparaisons pour des besoins spécifiques. Cela va à l'encontre (espérons-le) de l'état d'esprit de tous les développeurs selon lequel les choses devraient être aussi génériques que possible.

@ cal127 "Je crois que vous ne pouvez tout simplement pas considérer un seul si/sauf (sans conditionnel) comme logique" - Alors, quel est le problème alors ? Pourquoi la vérification d'une expression est-elle plus logique que la vérification d'une valeur booléenne ? C'est un chèque. Période. C'est la logique qui est faite ici, pas l'expression (puisqu'une valeur booléenne est - devinez quoi - une expression). Bien sûr, en supposant que l'expression ne représente pas une logique commerciale, mais une logique d'interface utilisateur.

Je suis désolé que l'idée de moteurs de modèles sans logique semble déjà moribonde... je ne vois pas cela continuer à l'avenir. Les développeurs ont besoin d'outils qui rendent les choses plus faciles et plus rapides, pas plus compliquées.

@thany rocks. Je suis tombé sur la moustache (un autre langage de modèle sans logique) hier et c'était exactement la question qui m'est venue à l'esprit quelques instants plus tard. Comment les programmeurs ont-ils pu penser que c'était cool. Cela ne fait qu'empirer les choses. Le paradigme de programmation que je connais est la "séparation de la logique BUSINESS de la logique PRESENTATION". Cette définition signifie qu'il y a une logique dans la présentation (vues qui contiennent/incluent des modèles dans un modèle comme mvc par exemple). Comment se fait-il qu'ils essaient de nier cela et de supprimer la logique de la présentation.

Scénario : j'exécute une boucle dans une vue et je souhaite effectuer une action après x itérations. Avec le guidon, je dois maintenant créer une aide, puis l'utiliser dans la boucle, n'est-ce pas ? en quoi cela me simplifie-t-il la vie ? Que s'est-il passé si count==x ????? En quoi est-ce mieux que d'utiliser un langage comme php lui-même pour vos modèles ? Comment cela aide-t-il à concevoir sur des moteurs de modèles logiques ?

Moi? Rien sans logique pour un travail orienté logique. Désolé!

Je ne peux pas croire à quel point vous pouvez être ignorants, chers partisans de l'absurdité. Ce n'est tout simplement pas une réalité, c'est un mythe complet, une erreur, une fausse religion. Aucun modèle de plus de quelques lignes ne sera jamais entièrement sans logique. Ce n'est tout simplement pas pratique.

Maintenant, imposer une telle croyance à vos utilisateurs est entièrement votre décision. Mais continuer à repousser toute demande de logique est une preuve de stupidité et d'ignorance. Surtout dans ce cas particulier, car il y a déjà une quantité de logique possible, quoique infime.

Encore une fois, je vous exhorte fortement à reconsidérer. Non, attendez, ne reconsidérez pas. Écoutez simplement et faites ce qu'il faut. Les gens qui ne veulent pas de cette logique idiote dans leurs modèles, peuvent aller de l'avant et continuer leurs mauvaises voies et sauter à travers toutes sortes de cerceaux afin de ne pas utiliser la logique.

L'extension du bloc if pour effectuer des comparaisons appropriées n'enlève pas son utilisation actuelle. Cela ne causera pas de problèmes à ceux qui n'ont pas encore vu la lumière logique, ces gens peuvent continuer à coder comme ils étaient.

Il ne s'agit pas de cool; vous utilisez vous-même la séparation de la logique de la présentation comme argument, puis l'ignorez pour demander que votre vie soit simplifiée. Vous auriez pu ajouter n'importe quelle bibliothèque de modèles de guidon standard à votre projet ou écrire la vôtre.

Vous ou personne d'autre n'avez abordé l'un des nombreux arguments contre cela dans l'un des nombreux fils de discussion. Juste pour que ces arguments soient clairs dans ce fil:
1) Vous allez perturber un écosystème existant ; ce qui provoquera des conflits et des retouches pour les équipes qui souhaitent mettre à jour mais qui ont leur propre FI depuis environ 2 ans.
2) Il existe des bibliothèques d'aide existantes qui ajouteront le si vous en avez besoin, ainsi que tous les autres assistants que vous demanderez ensuite.
3) Dès qu'il sera convenu d'ajouter ce « si », le nouvel argument en sera la mise en œuvre. Nom. Syntaxe. Arguments. Vous pouvez promettre d'être satisfait si cela se présente, mais d'autres ne le feront pas. Il y aura immédiatement un nouveau fil (s) ici, faisant valoir que cela devrait fonctionner d'une autre manière.
4) Le « si » existant est exactement ce qui devrait être là pour le -rendu-. "Afficher X si Y est présent". Il ne s'agit pas de logique métier ; ce qui devrait se produire dans votre modèle (je suggère Backbone, alors vous pouvez avoir ce que vous voulez que ce soit, juste être une méthode isXXX() sur votre modèle).

Puisque nous nous demandons des choses, s'il vous plaît ne continuez pas si vous n'avez pas un assez bon argument technique pour faire un changement majeur. Être frustré est idiot - Ajoutez le « SI » que vous voulez et c'est fait.

1) Non, vous ne le ferez pas. Si vous ne faites rien, les modèles devraient continuer à fonctionner. Bien sûr, tout doit être rétrocompatible. Et même si ce n'est pas le cas, ne procédez tout simplement pas à la mise à niveau.
2) Une instruction if est élémentaire. Ce que vous dites, c'est que les roues d'une voiture sont désormais optionnelles.
3) La syntaxe d'une instruction if a très peu d'importance. Chaque langage de programmation en a un, et chacun d'eux fait exactement la même chose. Alors choisissez-en un et tout ira bien. Plus important encore, avoir N'IMPORTE QUELLE instruction if appropriée est mieux que ce que nous avons actuellement.
4) Faux, recherchez vers le haut pour "template logic".

Quant à votre dernière position, l'argument _has_ a été avancé, et il est solide. Cela a été discuté maintes et maintes fois, mais cela ressemble vraiment à une religion. Incassable et pourtant si fragile.

George Frick -

1) En quoi est-ce différent de la mise à niveau de TOUT autre framework ou bibliothèque qui a déjà existé ?
2) Vous avez raison. Cependant, l'ajout manuel de ces fonctionnalités de base ne devrait pas être nécessaire pour quelque chose d'aussi fondamental et nécessaire.
3) C'est à cela que servent les Pull Requests.
4) Vous avez complètement raté le point. Personne sur ce fil ne plaide en faveur d'une logique métier dans la couche de vue. Nous plaidons pour une logique d'affichage UTILE dans la couche de vue. Le "si" donné n'est pas un vrai si, ce qui le rend déroutant pour quiconque a déjà utilisé un langage de programmation. C'est plus un "existe".

Si vous pensez que l'ajout de ceci amènerait les gens à utiliser la logique métier dans les modèles, vous avez probablement raison car vous ne pouvez pas réparer les stupidités. Ce n'est pas parce que quelqu'un PEUT faire quelque chose de mal que vous devez empêcher les autres de faire quelque chose de bien (et de nécessaire) dans le processus.

Le 22 novembre 2013 à 15h55, George Frick [email protected] a écrit :

Il ne s'agit pas de cool; vous utilisez vous-même la séparation de la logique de la présentation comme argument, puis l'ignorez pour demander que votre vie soit simplifiée. Vous auriez pu ajouter n'importe quelle bibliothèque de modèles de guidon standard à votre projet ou écrire la vôtre.

Vous ou personne d'autre n'avez abordé l'un des nombreux arguments contre cela dans l'un des nombreux fils de discussion. Juste ça pour que les arguments soient clairs dans ce fil :
1) Vous allez perturber un écosystème existant ; ce qui provoquera des conflits et des retouches pour les équipes qui souhaitent mettre à jour mais qui ont leur propre FI depuis environ 2 ans.
2) Il existe des bibliothèques d'aide existantes qui ajouteront le si vous en avez besoin, ainsi que tous les autres assistants que vous demanderez ensuite.
3) Dès qu'il sera convenu d'ajouter ce « si », le nouvel argument en sera la mise en œuvre. Nom. Syntaxe. Arguments. Vous pouvez promettre d'être satisfait si cela se présente, mais d'autres ne le feront pas. Il y aura immédiatement un nouveau fil (s) ici, faisant valoir que cela devrait fonctionner d'une autre manière.
4) Le « si » existant est exactement ce qui devrait être là pour le -rendu-. "Afficher X si Y est présent". Il ne s'agit pas de logique métier ; ce qui devrait se produire dans votre modèle (je suggère Backbone, alors vous pouvez avoir ce que vous voulez que ce soit, juste être une méthode isXXX() sur votre modèle).

Puisque nous nous demandons des choses, s'il vous plaît ne continuez pas si vous n'avez pas un assez bon argument technique pour faire un changement majeur. Être frustré est idiot - Ajoutez le « SI » que vous voulez et c'est fait.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

@thany
Il y a une différence entre réfuter un argument et le rejeter. "WRONG" équivaut à "NUH UH!".
Essayez de ne pas être si personnel à ce sujet non plus.

@tniswong
1) Ce n'est pas le cas, cela est vrai dans n'importe quel cadre.
2) Si vous appliquez cela dans un sens général, Node doit inclure tous ses composants. Le fait qu'ils soient fondamentaux ou nécessaires peut être soutenu mais conduirait à l'idée que les regrouper tous ensemble en dehors du cadre standard est une bonne abstraction et séparation. De nombreux projets n'en ont tout simplement pas besoin, et d'autres ont besoin de versions spéciales. Vous pouvez donc ajouter un ensemble standard, écrire le vôtre ou n'en utiliser aucun. Il n'y a (encore) aucune raison techniquement valable pour que tous ces assistants soient intégrés par défaut.
3) Votre déclaration ne nie en aucune façon le point initial, en fait - vous l'aidez. 20 demandes d'extraction pour corriger If. Je parie que l'équipe de développement adorera les parcourir.
4) Justement, c'est un 'existe'. Rendre ceci s'il existe.
Lorsque vous ne pouvez pas écrire sur « quiconque jamais », cela prend un seul contre-exemple. _à main levées_.

D'après les notes ci-dessus, il me semble que l'un des éléments suivants est nécessaire :

1. Renommez if en exists et arrêtez d'appeler les guidons "sans logique" (parce que ce n'est pas le cas)
2. Ajout du support pour que if se comporte comme une instruction if .
3. Supprimez complètement if .

Je serais heureux avec n'importe laquelle de ces options.

N'oubliez pas {{#à moins que}}

Le 22 novembre 2013 à 16h40, Aaron M [email protected] a écrit :

D'après les notes ci-dessus, il me semble que l'un des éléments suivants est nécessaire :

Renommez si existe et arrêtez d'appeler les guidons "sans logique" (parce que ce n'est pas le cas)
Ajout de la prise en charge de if pour se comporter comme une instruction if.
Supprimer si entièrement.
Je serais heureux avec n'importe laquelle de ces options.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

Je pense que ce à quoi cela se résume vraiment est bien résumé par Aaron.

1. Il y a une hypocrisie qui doit être corrigée en prétendant être sans logique ET en fournissant un si/un moins.
2. Le "si" donné est un terme impropre.

Réparez-les tous les deux, et cet argument disparaît.

Le 22 novembre 2013 à 16h43, Todd Niswonger [email protected] a écrit :

N'oubliez pas {{#à moins que}}

Le 22 novembre 2013 à 16h40, Aaron M [email protected] a écrit :

D'après les notes ci-dessus, il me semble que l'un des éléments suivants est nécessaire :

Renommez si existe et arrêtez d'appeler les guidons "sans logique" (parce que ce n'est pas le cas)
Ajout de la prise en charge de if pour se comporter comme une instruction if.
Supprimer si entièrement.
Je serais heureux avec n'importe laquelle de ces options.

-
Répondez directement à cet e-mail ou consultez-le sur GitHub.

@georgefrick
Je rejetais son argument simplement parce qu'il a été réfuté un million de fois auparavant. Cela fait bien trop longtemps que nous sommes sur ça, et ça doit cesser. La déclaration if doit être ajoutée, personne ne sera désavantagé et tout le monde sera content. Ne pas le vouloir revient à ne pas vouloir de climatisation dans TOUTES les maisons. Je serai juge de ce que je veux dans ma maison. Si c'est dans le vôtre et que vous n'en voulez pas, alors laissez-le. Aussi simple que cela.

@webgouverneur
Aucun changement de nom n'est nécessaire. Une instruction if appropriée peut être rendue entièrement compatible avec l'instruction actuelle. Actuellement, c'est juste "if booléen alors...", et toute instruction if complète fera exactement cela, seule cette chose booléenne peut maintenant être n'importe quelle expression plutôt qu'une seule variable.

@tniswong
Comme ils sont gentils, n'est-ce pas ? Pour ajouter une balise supplémentaire sale parce que le bloc if tel qu'ils l'ont implémenté est tellement simplifié qu'il ne peut même pas annuler une expression. Mais dans un futur Handlebars, la balise else peut simplement devenir un alias pour "if not". Un peu comme do..while versus while..do en programmation, où les deux existent principalement pour la lisibilité et pas _vraiment_ pour une raison technique.

Moi aussi, je souhaite des comparaisons de base dans les guidons. Je comprends la philosophie sans logique. Je pense également que le support de comparaison de base serait plus intuitif et permettrait aux utilisateurs de travailler plus efficacement. Si les utilisateurs en masse déplacent la logique de comparaison de base vers un assistant, cette philosophie ne leur rend pas service ou ne dissuade pas un comportement perçu sous-optimal - elle crée simplement plus de travail.

@jeremiahlee Je ne sais pas si vous êtes d'accord ou en désaccord avec moi, je peux lire votre commentaire de toute façon :)

Quoi qu'il en soit, j'ai travaillé avec Handlebars dans le passé et je leur ai demandé d'implémenter un bloc if approprié. Cela a entraîné une avalanche de commentaires sur une fausse philosophie selon laquelle la logique devrait rester dans le modèle. Aucun développeur de guidons ne souhaitait penser à un millimètre en dehors de son propre monde minuscule (il y a un mot grossier pour cela, mais je vais le sauter). Regardez ce fil comme preuve.

Cela m'a forcé à écrire une aide appelée "quand" qui fait des comparaisons. Toujours pas de construction if-block appropriée, mais assez proche pour moi à l'époque. Cela a créé beaucoup de travail inutile pour moi cependant.

@thany : Je suis d'accord pour dire que Handlebars devrait avoir une comparaison de base de deux valeurs intégrée. Les modèles sans logique ne devraient pas non plus être sans empathie.

Je voterai également pour @thany et les autres arguments. Les instructions if else sont bien trop basiques.
Les classes conditionnelles et les boîtes select avec des option présélectionnés devraient être réalisables avec le package de guidons par défaut.

Avec les aides imbriquées, ce n'est plus un problème, par exemple

{{#if (greater-than array.length 3)}}
  ...
{{/if}}

bon exemple @mmun :+1:

Un peu bizarre, et je ne vois pas de combinateurs booléens... Mais surtout, cela ne change pas le point de vue global des mainteneurs de ce projet, qui semble être un "NO LOGIC !!11 incassable !!" Type de vue 1!1".