Dies kann durch Helfer erfolgen.
Schau mal hier:
Es gibt einen ifequal-Helfer, der es ermöglicht, zwei Werte zu vergleichen.
Eine ähnliche Lösung kann für Ihre Anforderung verwendet werden.

Davor hatte ich Angst.
Ich weiß, dass so etwas mit Helfern gemacht werden kann ... Aber ich meine, das Vergleichen von Sachen ist so grundlegend, dass es im Standardpaket enthalten sein sollte.

Wenn es im Paket enthalten wäre, wäre es sowieso ein Helfer.

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

@andriijas ganz richtig, es wäre ja ein Helfer ;) Oder auch nicht, da ein if-Block so elementar ist.
Danke für den Link. Es ist hilfreich, aber es juckt mich, einen "Helfer" zu schreiben, der das ursprüngliche if überschreibt, um es zu einem _richtigen_ if zu machen. Ich bin sicher, es ist möglich. Jede Template-Engine mit Selbstachtung benötigt eine angemessene bedingte Formatierung. Lenker sollten keine Ausnahme sein.

Sie müssen über die Tatsache hinwegkommen, dass alles in Lenker, das Geschäftslogik auf Vorlagen anwendet, Helfer sind.

Alle eingebauten, if etc werden über registerHelper definiert. Prüfen:
https://github.com/wycats/handlebars.js/blob/master/lib/handlebars/base.js

Es ist also nichts "Schlechtes", Helfer zu verwenden. Handlebars ist mehr oder weniger nur ein Schnurrbart-Template-Compiler und um diese zusätzliche Geschäftslogik zu erhalten, verwenden sie Helfer. wenn du denkst du hast nur schlechte erfahrungen mit der verwendung des wortes "helfer" vielleicht von schienen oder so.

Ich habe nie gesagt, dass mit "Helfern" etwas nicht stimmt. Es ist nur so, dass eine richtige if-Anweisung meiner Meinung nach keine Erweiterung sein sollte. Ein Helfer (wiederum aus meiner Sicht) ist etwas Spezifisches für ein CMS oder so. Ein Helfer ist etwas, das eine spezielle Operation oder Bedingung ausführt. Etwas, das nicht jedermanns Sache ist. Das heißt, wenn es außerhalb der Kernbibliothek definiert ist. Ein bisschen wie jQuery-Plugins vielleicht: Die elementarsten Dinge sind eingebaut, die Dinge, die einem den Einstieg erleichtern. Aber Dinge, die nicht jedermanns Sache sind, werden außerhalb der Kernbibliothek (dh in Plugins) definiert. In jQuery-Begriffen wäre eine einfache Filterfunktion kein Plugin.

Eine if-Anweisung (aus meiner Sicht) trifft auf dieses Plugin-Paradigma nicht zu. Es ist elementar, es ist eines der grundlegendsten Prinzipien der Programmierung und der Template-Engines...

Dann eine kurze Nachverfolgung. Folgendes habe ich bisher:

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

Wenn ich dies in meiner Vorlage wie {{#when riskfactor eq 0}}...{{/when}} erhalte ich in meiner Konsole ein Array von [6, undefined, 0, function()] . Das letzte was ich bekomme. Das ist es, was ich aufrufen muss, um den Inhalt dieses Wenn-Blocks zu verarbeiten. Die ersten drei... na ja, nicht so sehr. Die "6" ist eigentlich der Wert von "Risikofaktor". Okay, damit kann ich gehen. Das Undefinierte ist mir nicht möglich. Ich denke, Handlebars versucht, es am Eingabeobjekt auszuwerten, aber das funktioniert nicht. Ich möchte Dinge erhalten, die tatsächlich _in_ der Vorlage sind, weil Werte wie diese nichts mit meinem Objekt zu tun haben.

Ich habe so etwas wie ["riskfactor", "eq", "0", function()] erwartet. Nur dann kann meine Funktion weitermachen und das verarbeiten. Wie soll ich das mit "undefiniert" machen?

Ich denke, die Philosophie von Handlebars (und anderen "logiklosen" Vorlagen) besteht darin, dass der Kontext, der für die Vorlage ankommt, bereits vollständig verarbeitet sein sollte. Wenn die internen Datenstrukturen Ihrer Anwendung nicht perfekt mit dem übereinstimmen, was für eine Vorlage geeignet wäre (was fast jedes Mal der Fall ist), sollten Sie vor dem Rendern der Vorlage einen Schritt einfügen, der den Vorlagenkontext aus den internen Daten Ihrer Anwendung erstellt Strukturen.

Ich glaube, das ist die Absicht, wenn man davon spricht, "Logik von Präsentation zu trennen". Stellen Sie sich Lenker als die Ansichtskomponente eines MVC-Systems vor. Ihr Modell existiert bereits; Alles, was Sie jetzt schreiben müssen, ist der Controller (in diesem Fall ist es ein Satz unidirektionaler Bindungen vom Modell zur Ansicht).

Um Ihre letzte Frage zu beantworten, möchten Sie Folgendes verwenden:

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

Handlebars-Ausdrücke sind entweder Variablennamen oder Strings. Wenn es sich um einen Variablennamen handelt, erhalten Sie beim Nachschlagen im aktuellen Kontext den Wert der Variablen, nicht den Namen.

Dies liegt außerhalb des Bereichs von Lenkern, wie einige darauf hingewiesen haben.

Nein.
JEDES Template-System kann einen einfachen vergleichenden If-Else-Block ausführen, und Handlebars kann dies nicht. Das macht Handlebars entweder lächerlich unvollständig, seine Hersteller inkompetent (was unwahrscheinlich ist) oder ein System mit einer getrübten Perspektive auf die Aufgaben eines Templating-Systems.

VERWENDEN SIE DANN KEINE LOGICLESS TEMPLATE ENGINE. KTHXBAI!

Ich habs. Toodles.

@thany , @andriijas war wahrscheinlich etwas hart, aber er hat recht. Lenker soll ohne Logik sein. Sie können definitiv ein Fahrrad mit einem Motor herstellen, aber viele Unternehmen stellen gerne nur motorlose Fahrräder her. Ebenso können Sie ein Vorlagensystem mit mehr Logik erstellen, aber das ist nicht etwas, was Handlebars versucht. Es ist leider nicht das, wonach Sie gesucht haben.

Ich muss @thany auf der Seite des if Helfers stehen. Wir sollten in der Lage sein, jedes Prädikat hineinzugeben. Nicht in der Lage zu sein, seinen Nutzen wirklich einzuschränken. Ich verstehe die Philosophie hinter logiklosen Vorlagen, aber eine dogmatische Implementierung ist nicht wirklich pragmatisch (und damit die Existenz der Helfer, oder?). Ich würde sagen, dies ist eher so, dass die Fahrradfirma eine variable Übersetzung hinzufügt, was völlig vernünftig wäre.

Übrigens, wenn Sie gegen die Maschine wüten möchten und dies tun möchten, können Sie einen Helfer erstellen, der das Prädikat als String nimmt und es dann auswertet (und dies zweimal ketzerisch machen :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 schau es dir aus der Best-Practice-Perspektive an, dein Back-End sollte die Daten mit der bereits herausgefundenen Logik http://handlebarsjs.com/#conditionals

Im Ernst, nicht ALLE (oder sogar 95%) getroffenen Entscheidungen sind Backend-orientiert. Um beispielsweise zu bestimmen, welcher Klassenname gerendert werden soll, ist es durchaus sinnvoll, diese Entscheidung in der Vorlage zu treffen. So etwas ist zu 100% an das Frontend/Template gebunden. Dem Backend ist es egal, welcher Klassenname gerendert wird. Oder was ist mit Singular/Plural-Wörtern? Das ist eine andere Sache, die mit dem if-Block nicht möglich ist.

Das Backend ist meiner Meinung nach für die Bereitstellung von Daten verantwortlich, und zwar NUR für Daten, wenn mit solchen Rich-Templates gearbeitet wird. Wenn das Backend dem Template-Parser vorgefertigte Variablen für jede einzelne Situation geben muss, über die das Template möglicherweise eine Entscheidung treffen könnte (wobei hier eine gewisse Flexibilität berücksichtigt wird), wären sie allein durch die schiere Menge an Variablen lächerlich kompliziert, geschweige denn die Backend, das sie macht.

Sie können auch HTML in das Backend einfügen, wenn jede Entscheidung, die ein Template benötigt, eine weitere Modifikation im Backend erfordert. Das nimmt nur einen großen Teil des Zwecks von Vorlagen. Entscheidungen, die an das Backend gebunden sind, liegen auf einer ganz anderen Ebene. Ein if-Block ist nicht unbedingt logisch. Es ist nur zu entscheiden, was/wie gerendert werden soll.

Ich kann nicht glauben, dass dieses Problem eine so lange Diskussion erfordert, ist ein richtiger Wenn-Block wirklich zu viel verlangt? :(

Ich werde weder für noch gegen die Implementierung eines einfachen Vergleichshelfers argumentieren, aber dies ist der sehr reale Fall, in dem ich glaube, dass ich die Vorlage nicht hätte rendern können, ohne einen Helfer zu verwenden oder die Datenstruktur zu ändern:

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

Aber andererseits bestand der von mir geschriebene Helfer aus drei Codezeilen:

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

Ich stimme @thany zu , ich glaube auch nicht, dass dies außerhalb der Vorlage / Ansicht sein sollte.

Warum kann eine Vorlage keine Logik enthalten? und wie sorgt der lenker für eine trennung von logik und darstellung? es hat immer noch eine if Anweisung, nicht wahr? Wollen Sie damit sagen, dass eine if Anweisung, die einfach auf Existenz und/oder "Falschheit" prüft, sich in keiner Weise von einer if Anweisung unterscheidet, die auf (Un-)Gleichheit oder andere Bedingungen prüft?

der einzige – wirkliche – Unterschied besteht darin, dass Lenker im Gegensatz zu anderen Template-Bibliotheken eine sehr schlechte/unvollständige Implementierung der genannten Logik unter dem Vorwand haben, "logiklos" zu sein. tut mir leid, aber das ist völlig unsinnig. Wenn Sie die Logik entfernen möchten, sollten Sie die Anweisung if vollständig entfernen. Sie werden dies jedoch nicht tun, denn letztendlich benötigt eine Vorlage Logik aus den gleichen Gründen, warum Lenker immer noch eine if Anweisung haben.

also die Aussage "Logik von Präsentation trennen". ist irreführend, nicht nur aus den oben genannten Gründen, sondern auch, weil Sie die "Logik" nicht aus der Vorlage entfernen, sondern sie einfach in einen anderen Teil der Vorlage verschieben - dh in den Helfer - und möglicherweise erhalten Sie Code-Wiederverwendung - was eine gute Sache wäre – und vielleicht auch nicht, in diesem Fall können Sie eine beliebige Anzahl von Helfern bekommen, die fast / genau das gleiche wie andere Helfer ausführen, aufgrund eines geringfügigen Unterschieds, der durch eine korrekte Implementierung von besser gewesen wäre if . Wie ist das eine gute Designentscheidung?

Ich habe immer noch Probleme zu verstehen, warum, wenn eine bestimmte "Logik" von Natur aus an eine bestimmte Sichtweise gebunden ist und für nichts anderes als die Sichtweise selbst von Bedeutung, Bedeutung und / oder Nutzen ist, was genau das Problem ist. es klingt für mich einfach nach mvc extremismus/overkill.

@andriijas Wenn ich eine andere Vorlagenbibliothek verwenden könnte, würde ich es

Hat sich schon mal jemand angeschaut, wie das aktuelle if umgesetzt wird? (es gibt es auch, es sei denn, was ist schön)

Nun, da Sie sich angesehen haben, wie das if derzeit implementiert ist, könnte es für Sie sinnvoller sein, warum Lenker eine einfache und elegante Standardeinstellung haben, die die meisten Leute zufriedenstellt.

Schau hier, wie einfach es zu verlängern ist

https://github.com/elving/swag

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

Akzeptieren Sie, dass alle Ihre Open-Source-Projekte nicht alles bieten, was Sie brauchen, um Ihren Speck zu kochen, nur die Grundlagen.

@andriijas ja, unless ist nur ein if mit invertiertem Ergebnis. Ich sehe nicht, wie das alles kompensiert. Danke für den Repo-Link der Helfer, ich habe bereits einen Helfer geschrieben, aber ich sehe nicht, wie dies etwas kompensiert.

Lenker ist etwas über 10kb (minzipped) und Swag ist etwas unter 3kb (minzipped). Sie fügen also Ihrer Codebasis eine 10kb-Vorlagenbibliothek hinzu und Sie benötigen weitere 3kb, um Ihren Vorlagen Logik hinzufügen zu können. Logik, von der Sie und einige andere sagen, dass Sie sie sowieso nicht in Ihren Vorlagen haben sollten?

Dies beantwortet keine meiner Fragen und dient nur dazu, den Punkt zu beweisen, dass es unsinnig ist, andere bedingte Tests als Existenz/Falschheit in Ihrem if Anweisungsblock zu verbieten.

@andriijas Ich /lib/handlebars/base.js#L97 an , bin mir aber nicht wirklich sicher, was du meinst. Es sieht so aus, als ob es eine alternative Verwendung gibt, aber die Dokumentation gibt dies nicht an. Möchten Sie es erklären?

@constantology einige Leute brauchen vielleicht weitere 3kb, du und die anderen Leute in diesem Thread zum Beispiel. Der Rest der 3500, die dieses Repo auf github spielten, wird sich wahrscheinlich nicht beschweren, da sie ihre logischen Bedürfnisse entweder durch Hinzufügen von Helfern oder durch das Ausführen der Vorlagen vor dem Rendern der Vorlagen gelöst haben.

@piksel, was Sie sich

Es ist nichts falsch daran, Helfer in Ihrem Projekt zu verwenden. In einem Projekt verwende ich einige der Swag-Helfer, die in meine eigene view_helper-Datei kopiert wurden, sodass es sogar weniger als 3k ist.

In einem Backbone-Projekt habe ich eine getTemplateData-Methode in meinen Ansichten, bei der ich komplexe Logik auf einfachere Dinge herunterreduziere, die die Vorlagen sauberer und einfacher zu befolgen machen, ah und außerdem ist es einfacher, einfaches Javascript zu testen als Lenkervorlagen.

@andriijas das beantwortet immer noch keine meiner Fragen...

An dieser Stelle möchte ich nur wiederholen, was ich bereits gesagt habe. Wenn Sie also das Gefühl haben, eine vernünftige Antwort auf eine oder alle Fragen geben zu können, die ich bereits gestellt habe, würde ich mich sehr freuen, zu hören, was Sie tun müssen sagen. :)

ps Die Anzahl der Personen, die das Repo markiert haben und/oder die Bibliothek verwenden, ist nicht unbedingt ein Hinweis darauf, wie gut eine Bibliothek ist. Es gibt mehr Windows-Benutzer als Mac/Linux zusammen und – je nachdem, welche Browser-Statistik-Site Sie sich ansehen – verwenden immer noch mehr Leute den Internet Explorer 6, 7 und 8 zusammen als einen moderneren Browser. das macht windows nicht zu einem besseren betriebssystem als osx oder linux und macht ältere versionen des internet Explorers nicht besser als moderne standardkonforme browser.

Diese ganze Diskussion ist mir blöd. Ein if Helfer ist da, ES IST LOGIK. Das ganze logiklose Argument ist also ein totaler Strohmann. Es ist, als ob ein Auto Fenster hätte, die sich nur herunterklappen ließen und die Leute sich beschwerten und wollten, dass sie auch hochfahren. Und die Hersteller sagten, sie würden es nicht ändern, weil diese Autos einer strengen Philosophie folgten, keine mechanisch gesteuerten Fenster zu haben ... Entweder Sie unterstützen es oder Sie tun es nicht. Eine halbherzige Umsetzung sollte nicht mit einem Strohmann-Argument begründet werden.

Ich stimme voll und ganz zu und verstehe, dass keine Geschäftslogik in Vorlagen enthalten ist. Aber wenn Sie nicht extrem triviale Vorlagen verwenden, haben Sie dort eine Ansichtslogik . Handlebars erkennt dies offensichtlich, da der if Helfer existiert. Das Umgehen eines behinderten if Helfers durch Hinzufügen einer Reihe von Ansichtslogiken in Ihrem Code ist nicht die Antwort, wie @thany darauf hingewiesen hat. Hab ich schon mal gemacht, es wird schnell hässlich.

@mikeobrien ja, das habe ich bereits in einem früheren Kommentar erwähnt . Es war eine von vielen Fragen, die unbeantwortet geblieben sind.

Ich stimme voll und ganz zu und verstehe, dass keine Geschäftslogik in Vorlagen enthalten ist. Aber wenn Sie nicht extrem triviale Vorlagen verwenden, haben Sie dort eine Ansichtslogik.

schön gesagt. :^)

@constantology doh, sorry, ich hätte die letzten Kommentare besser lesen sollen. :/

Ich stimme @constantology zu

FWIW Ich finde Handlebars eine wirklich elegante und gut geschriebene Vorlagenbibliothek.

Ich verstehe das Konzept von Blöcken und Helfern gut, aber ich glaube nicht, dass das Erstellen eines Helfers für etwas Kleines – das durch Unterstützung in der Kernbibliothek eleganter gehandhabt werden könnte – eine klare Trennung von Logik und Präsentation bedeutet. CSS fügt Unterstützung für bedingte Anweisungen hinzu und einiges davon kann bereits mit Medienabfragen erreicht werden, daher ist Logik in einer reinen Präsentationssprache nicht unbedingt ein großes Boo-Boo, wenn es einfach "Ansichtslogik" ist, wie @mikeobrien es ausdrückt.

Ich glaube, dass diese eine Einschränkung – das Fehlen von bedingten Prüfungen in if / unless Blöcken – es wirklich schwierig macht, elegante und gekapselte Vorlagen zu erstellen.

Außerdem bin ich damit einverstanden, eine Methode zur Vorverarbeitung von Daten zu haben, bevor sie durch eine Vorlage geparst wird, jedoch nur für einfache Änderungen, nicht für die Neuformatierung der gesamten Datenstruktur, um sie dem Willen einer Bibliothek zu unterwerfen. Wieso den?

1. Dies könnte möglicherweise die Gesamtleistung des Parsens beeinträchtigen, wenn Sie eine komplexe Datenstruktur verwenden und etwas flacheres erstellen müssen.
2. basierend auf 1 , kann es möglicherweise Ihren View-Code brüchiger machen – und schwieriger zu refaktorisieren –, wenn Änderungen am ursprünglichen Schema vorgenommen werden.
3. es könnte auch die bidirektionale Datenbindung schwieriger machen, da Sie die ursprüngliche Datenstruktur nicht mehr der Ansicht zuordnen, wodurch die Menge an Code erhöht wird, die Sie möglicherweise zum Nachverfolgen von Änderungen benötigen.

Das sind mir nur aus dem Kopf gegangen, ich habe keine quantifizierbaren Nachforschungen angestellt, um das zu untermauern, aber es ist ein Denkanstoß. :^)

für die ursprüngliche frage wäre ein if-Helfer mit vergleich das falsche. Es ist ein gängiges Szenario und Helfer wie:
{{#ifzero count}}Keine Ergebnisse{{/ifzero}}
{{#ifsingular count}}1 Ergebnis{{/ifsingular}}
{{#ifplural count}}{{count}} Ergebnisse{{/ifplural}}
wäre hilfreicher und würde übersetzen, was er wirklich tun möchte. die aktuelle if-Syntax ist nützlich, um leere Werte (nicht) anzuzeigen. auch ein sehr häufiges szenario. Wenn jemand wirklich ein Wenn mit Vergleich braucht, ist es sehr wahrscheinlich, dass es Geschäftslogik ist und er es nicht in der Vorlage tun sollte.

Das würde es tatsächlich tun.
Ich denke aber immer noch, dass es nicht an einer Engine liegt, Entwickler in eine bestimmte Ecke zu zwingen, ob das nun _im Prinzip_ eine gute Ecke ist oder nicht. Ich denke, es sollte am Entwickler liegen, was Geschäftslogik und was Vorlagenlogik ist.

Das heißt, es sei denn, die Einschränkung, Vergleiche nicht durchführen zu können, ist eine rein technische Einschränkung, die es irgendwie zu einem Paradigma gemacht hat. Das bedeutet nur, dass eine solche Funktionalität im Bedarfsfall niemals hinzugefügt werden kann. Ich hoffe, das ist nicht passiert.

Testen Danke. Testen. Sie möchten keine Vergleiche in Vorlagen einfügen, da Sie diese Logik nicht einfach testen können. Es ist viel einfacher, einfache boolesche Werte über einen Datenformatierer für Ihre Vorlage zu erstellen und zu testen, als sich in etwas wie Selen einzuklinken und es dort zu testen.

Das ist nicht nur Theorie, das ist nicht nur „im Prinzip“. Es wäre wahrscheinlich echter technischer Schulden-Bullshit, sogar Vergleiche in Vorlagen zu setzen und diese Logik nicht zu testen. Schreiben oder verwenden Sie diese Helfer nicht. Ich habe noch keinen Helfer für Lenker verwendet. Wenn Sie jedoch einen Helfer verwendet haben, können Sie ihn ausspionieren und testen, um sicherzustellen, dass das Ding läuft. Es ist also besser als Vergleiche, die in die Vorlagen eingebaut werden.

Es gibt viele logikfreie Vorlagensysteme, die keine Vergleiche anbieten. Was bedeutet zum Beispiel in stark typisierten Sprachen wie go überhaupt Gleichheit? Es gibt keine Vergleiche in Go-Vorlagen. Es gibt Schnurrbart- und Lenkerimplementierungen in allen Sprachen und sie sind gleich.

Das Entfernen von Logik wie Vergleichen aus Vorlagen macht Ihr Leben nicht schwerer, sondern einfacher. Technische Schulden sind kein Witz, sie können Produkte und sogar Unternehmen ruinieren.

Komm schon.
Vergleiche sind nicht so schwer. Es ist keine Raketenwissenschaft (oder Gehirnchirurgie).

In sehr einfachen Microtemplates brauchen Sie keine Logik, aber wenn es komplizierter wird, brauchen Sie Logik in Templates. Es gibt so etwas wie "Geschäftslogik" sowie "Vorlagenlogik". Bestimmen, was zu tun ist, wenn von etwas nur ein Element vorhanden ist, oder zwei oder zehn. Paging zum Beispiel. Teiler. Einfache "unter 50%" & "über 50%" Texte, und ich könnte weitermachen.

Die Tatsache, dass auch andere Template-Engines keine Logik enthalten, bedeutet nicht, dass Sie ihnen blind folgen sollten. Sie haben es meiner Meinung nach auch falsch.

Tatsache ist, dass Sie irgendwann eine Art von Logik haben werden, die Sie in der Geschäftslogik einfach nicht brauchen oder wollen, einfach weil es keine Geschäftslogik ist. Ich kann meinen Entwicklerkollegen nicht mitteilen, dass sie für jede erdenkliche Art von Vergleich, die eine aktuelle oder zukünftige Vorlage jemals benötigen könnte, einen booleschen Wert haben.

"Es kann Produkte und sogar Unternehmen ruinieren"? Ernsthaft?
Unsachgemäße Funktionalität kann auch.

Was ist falsch daran, das zu versenden, was die meisten Leute brauchen, und Sie fügen einen Helfer hinzu?
für was brauchst du? Jeder gewinnt. Es ist nicht so schwer, nicht wie Rakete
Wissenschaft.

Wenn es Raketenwissenschaft ist: https://github.com/elving/swag

Am Samstag, 18. Mai 2013, schrieb thany:

Komm schon.
Vergleiche sind nicht so schwer. Es ist keine Raketenwissenschaft (oder Gehirnchirurgie).

In sehr einfachen Mikrotemplates braucht man keine Logik, aber wenn sie welche bekommt
komplizierter, Sie benötigen Logik in Vorlagen. Es gibt sowas
Ding als "Geschäftslogik" sowie "Vorlagenlogik". Bestimmen, was zu tun ist
tun, wenn es nur ein Element von etwas gibt, oder zwei oder zehn. Paging, für
Beispiel. Teiler. Einfache "unter 50%" & "über 50%" Texte, und ich könnte weitermachen.

Die Tatsache, dass auch andere Template-Engines keine Logik enthalten,
bedeutet nicht, dass Sie ihnen blind folgen sollten. Sie haben es auch falsch in meinem
Meinung.

Tatsache ist, dass du irgendwann eine Art Logik haben wirst, die du einfach
in der Geschäftslogik nicht brauchen oder wollen, einfach weil es kein Geschäft ist
Logik. Ich kann meinen Entwicklerkollegen nicht mitteilen, dass sie einen booleschen Wert haben
in, für jede erdenkliche Art von Vergleich, den jede gegenwärtige oder zukünftige
Vorlage jemals brauchen könnte.

"Es kann Produkte und sogar Unternehmen ruinieren"? Ernsthaft?
Unsachgemäße Funktionalität kann auch.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf Gi tHub anhttps://github.com/wycats/handlebars.js/issues/206#issuecomment -18104713
.

Die meisten Leute, die es _nicht_ verwenden, können an dem hier beschriebenen Problem liegen: keine Logik. Also werden die meisten Leute, die es aktiv nutzen, natürlich mehr oder weniger zufrieden damit sein.

@thany ich fühle dich und ich stimme dir zu.

Ich denke, die Leute hinter dem Lenker wollen das nicht aufgeben, aber hey, was ich dir sagen werde, sind erstaunliche Neuigkeiten:
Sie können das Projekt _forken_ , den Patch hinzufügen und Ihren eigenen Fork verwenden.
Aufgrund der Magie von git sollte es ziemlich einfach sein, mit nur git pull ing mit neuen Versionen Schritt zu halten.

Und warte ab, es wird besser.

Wenn dies ein großer Bedarf ist und es insgesamt besser ist, werden die Leute vielleicht anfangen, deine Gabel zu benutzen, oder noch besser, die Jungs hinter dem Lenker werden deine Gabel zurück zum Ursprung / Meister führen :dancer:

lass es dir gut gehen ;D

Wenn ich mir die Zeit gönnen würde, klar!

Ich stimme @constantology absolut zu. Es ist wahnsinnig, Vorlage ohne Logik zu haben. Und wenn Sie eine logiklose Vorlage haben wollten, warum Sie dort die: "wenn"-Anweisung setzen, was Logik als rote Farbe darstellt Gefahr ... Macht keinen Sinn. Ich denke, die grundlegende Vergleichslogik ist als Salz in der Suppe erforderlich. @mikeobrien :"Eine halbherzige Implementierung sollte nicht mit einem Strohmann-Argument gerechtfertigt werden." :+1:

Es gibt etwas zu sagen für logische Vorlagen. Ich glaube jedoch, dass das Problem darin besteht, dass hier jeder die Geschäftslogik mit der Ansichtslogik verwechselt. Geschäftslogik hat keinen Platz in Vorlagen. Zeitraum. Ansichtslogik ist jedoch eine ganz andere Sache. Ich denke, Handlebars hat dies erkannt, weshalb sie das if/else in erster Linie hinzugefügt haben, sie waren auf dem Weg nur ein wenig verwirrt.

Ich muss wissen, ob mein Daten-Array ein oder mehrere Elemente enthält, und basierend darauf möchte ich sie mit Kommas verbinden oder einem Wort einen Plural hinzufügen. Mit dem aktuellen if-Block kann ich dies nicht tun.

Aus diesem Grund habe ich diesen Pull-Request gemacht: https://github.com/wycats/handlebars.js/pull/566 und begleitendes jsfiddle: http://jsfiddle.net/YsteK/

Dieser Pull-Request liefert einen neuen Helfer: ifTest, der einen Javascript-Ausdruck annimmt, der genauso ausgewertet wird, wie Javascript den Kontext gegeben würde. Genießen.

Ehrlich gesagt ist dies eine so grundlegende Funktionalität, dass ich das Gefühl habe, dass Sie die Verwendung logischer Begriffe wie "wenn" überdenken müssen, wenn Sie an dieser Denkweise festhalten möchten, dass keine Logik in das Framework integriert ist (was mir völlig unlogisch erscheint!). .

Ich füge dies vielen meiner Projekte hinzu, einfach weil es so hilfreich ist, wenn ich Dinge wie "0" und "1" mit anderen booleschen Werten vergleiche:

Handlebars.registerHelper('ifCond', function(v1, v2, options) {
if(v1 === v2) {
return options.fn(dies);
}
Rückgabeoptionen.inverse(diese);
});

Ich denke, es ist völlig fair, die vorhandene "Wenn"-Funktionalität so zu gestalten, wie sie es tut, aber tun Sie der englischen Sprache einen Gefallen und wählen Sie ein anderes Wort (oder lassen Sie es tun, was die Leute erwarten). Es fühlt sich wie eine echte Perversion des Begriffs "wenn" an, wenn er sich in keinem anderen Kontext wie eine wahre if-Aussage verhält.

Ich möchte eine weitere Stimme hinzufügen, um entweder if vollständig zu entfernen oder if zu erlauben, einige grundlegende Vergleichsargumente zu akzeptieren, z. B. eq , ne , gt , etc. Am Ende hättest du {{#if arg1 eq arg2}} . Natürlich wäre das vollständige Entfernen von if für Ihre Philosophie "keine Logik in Vorlagen" sinnvoller (im Moment ist es eher wie "keine Logik in Vorlagen _die meiste Zeit_ aber _manchmal_ ist es okay").

Ohne Helfer mache ich ständig solche Sachen:

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

Was irgendwie albern erscheint, einem Objekt all diese zusätzlichen Eigenschaften hinzuzufügen.

webgovernor - Schau dir das an: http://jsfiddle.net/YsteK/

Es ist ein Helfer, der diese Funktionalität ermöglicht. Es braucht einen Javascript-Ausdruck, der genau so ausgewertet wird, wie Javascript den Kontext gegeben hätte. Genießen.

Danke Tniswong, das ist meinem Helfer sehr ähnlich. Ich habe das Problem gelöst, ich wollte nur die Heuchelei des "logiklosen" Dogmas des Lenkers hervorheben.

Kein Problem. Ich bin gleich bei dir. Ich liebe Lenker, aber ohne diesen Helfer ist es ziemlich nutzlos.

Ich habe diesen Helfer als Pull-Request eingereicht, aber er wurde abgelehnt. Also habe ich einen weiteren Pull-Request gesendet, der den if-Block entfernt hat. Auch abgelehnt. /Seufzen

Hahaha. Github benötigt einen Upvote-Button.

Es wurde abgelehnt? -_-

Die Sturheit der logischlosen Religion von Handlebars ist wirklich überwältigend.

566 und #568

Er erwähnte, dass er es vielleicht in die README-Datei aufnehmen würde, aber ich halte nicht den Atem an.

+1 dazu! Arghhh!

FWIW, das Swag- Repo, bietet Helfer, die Vergleiche, Sortierungen und andere raffinierte Dinge hinzufügen. Ich baue nichts in Handlebars ohne es.

Trotzdem stimme ich persönlich zu, dass der Lenker so logisch wie möglich bleibt, da er sauber, erweiterbar und wartbar bleibt. Wenn Sie mehr wollen, tragen Sie zu einem Repo wie _Swag_ für Dinge bei, die außerhalb des Projektumfangs liegen. Sollten die Betreuer dieses Projekts ihre Meinung ändern, genügt ein Pull-Request :+1:

@aboutaaron Wenn Sie eine Aussage machen wie "Lenker so logisch wie möglich bleiben lassen, da sie sauber, erweiterbar und wartbar bleiben", sollten Sie zumindest den Anstand haben:

1. beweisen, dass Lenker keine Logik enthalten. Wenn Sie den Thread gelesen haben, dann werden Sie sehen, dass bereits nachgewiesen wurde, dass Lenker eine unvollständige Logik in Form einer if Anweisung enthalten, die nur auf "Wahrheit" prüft, wenn Sie den Thread nicht durchgelesen haben, dann I würde dir vorschlagen, dies zu tun.
2. beweisen, dass Lenker, die unvollständige Logik liefern, in Form einer if Anweisung, die nur auf "Wahrheit" überprüft, in gewisser Weise "sie sauber, erweiterbar und wartbar hält".
   Ist das nicht ein Widerspruch? Wenn Lenker erweiterbar sind, bedeutet das nicht, dass es trivial wäre, eine vollständige Implementierung von bedingten Anweisungen bereitzustellen?
   Wie würde zum Beispiel ein Lenker, der eine vollständige if Anweisung liefert, ihn weniger sauber, erweiterbar und wartbar machen als ein Entwickler, der Lenker UND Swag verwendet ?
   Man könnte argumentieren, dass die Verwendung der Swag- Helfer eine Codebasis weniger sauber, erweiterbar und wartbar macht, da Sie für jeden Vergleichsoperator einen anderen Helfer verwenden müssen, dh gt , gte , is , isnt , lt , lte sowie für jeden logischen Operator, also and , or .
   Inwiefern macht dies den Code lesbarer, als dies alles so zu tun, wie man es in einer if -Anweisung in einer anderen Sprache tun würde? Wenn dies der Fall wäre, würde ich davon ausgehen, dass Programmiersprachen selbst bedingte Anweisungen abschaffen würden, die auf etwas anderes als "Wahrheit" prüfen? Ich sehe das nicht.

Wenn Sie zufällig das müde – und widerlegte – Argument verwenden, "Geschäftslogik in die Vorlage aufzunehmen", tun Sie es bitte nicht. dies wurde bereits – mehrmals, von mehreren Personen – in diesem Thread angesprochen. Wenn Sie dies gleichzeitig für ein gültiges Argument halten, würde dies die Verwendung der Swag- Bibliothek

Zusammenfassend lässt sich sagen, dass die Tatsache, dass es mehrere Bibliotheken gibt, die versuchen, die unvollständige Implementierung von if in Lenkern – auf die eine oder andere Weise – zu vervollständigen, dass diese Art von Funktionalität in ihren Ader. Schauen Sie sich die JavaScript-Sprache selbst an, Harmony führt viele Funktionen ein, die von Bibliotheken, Iteratoren, Modulen, Generatoren, Klassen, Proxys usw. von Drittanbietern bereitgestellt wurden; und die DOM-API hat auch Funktionen implementiert, die von Drittanbieter-Bibliotheken, querySelector[All], CORS bereitgestellt wurden, und es gibt sogar eine Implementierung von DOM-Versprechen in Chrome Canary.

Es gibt keinen Beweis dafür, dass "Lenker so logisch wie möglich bleiben, da er sauber, erweiterbar und wartbar bleibt". Gleichzeitig haben andere und ich – in früheren Kommentaren dieses Threads – gezeigt, dass ein wenig viel bewirken kann, wenn Lenker eine vollständige if Implementierung bereitstellen würden, würde es Entwicklern eine einheitliche API geben, die sie erstellen können ihre Vorlagen einfacher zu lesen und zu pflegen.

@constantology +1 Amen.

Ich bin gerade hier angekommen, nachdem ich {{#if etwas > etwas_else}} ausprobiert und die Wahrheit dieser Situation erkannt habe. Ich bin jedoch versucht, den Lenkerleuten in diesem Punkt zuzustimmen. Ich habe lange Zeit Liquid verwendet, und Kommentarthreads wie dieser führen unweigerlich dazu, dass unausgegorene Funktionen wie Mathematik und String-Verkettung hinzugefügt werden, die wirklich ins Backend gehörten.

Das Ziel mit der "logik-less" if-Anweisung scheint zu sein: Erledige den logischen Teil am Backend und präsentiere Lenker mit der "Antwort" als einzelne Variable. Wenn die Antwort "ja" lautet, tun Sie dies, ansonsten tun Sie das andere. Ich sehe darin kein Problem (nachdem ich die obigen Kommentare gelesen habe) und werde meinen Code jetzt reparieren.

Arbeite an einigen Ember-Anwendungen und wollte meine Meinung einwerfen. Ich glaube, dass die #if Anweisung besser wäre, wenn sie _(optional)_ ein Argument akzeptiert. Ich verstehe total den Wunsch, Dinge logic-less , aber es kann manchmal ziemlich frustrierend sein, damit zu arbeiten.

Stellen Sie sich eine einfache Liste von Fragen vor, die an- oder abgewählt werden können. Was ist eigentlich der Unterschied zwischen diesen beiden Logikblöcken?

{{#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}}

Es gibt ziemlich große Unterschiede, wie ich den Code schreiben muss, der diese beiden Beispiele unterstützt. Es wäre wirklich schön, auch die Flexibilität zu haben, zu wählen. Ich verstehe auch nicht wirklich, wie die erste mehr Logik enthält als die zweite.

Mir ging es genau so wie in diesem Thread. Dann habe ich diesen Thread gefunden.
Daher vermute ich, dass ich gerade die Philosophie des Lenkers verstanden habe.
Dann habe ich herausgefunden, dass ich eine Helfersammlung wie Swag brauche.

Jetzt habe ich kein Problem, denn Swag wird mir helfen.
Ich war jedoch verwirrt, weil der Standard-Helfer if zu einfach war.
Wenn Sie sagen, dass Hanlebars keine Logik hat, bezweifle ich, dass Handlebars eingebaute Helfer braucht.
Wenn es keine eingebauten Helfer hätte, denke ich, dass ich die Philosophie von Handlebars leichter verstehen könnte.

Ich habe vielleicht kein gutes Verständnis von logic-less und business logic , ich möchte Ihnen sagen, was ich dachte.

Ich glaube, dass Sie ein einzelnes if/es sei denn (ohne Bedingungen) einfach nicht als Logik betrachten können, da es nur - im logiklosen Kontext - ein Mittel ist, um boolesche Daten als "{{foo}}" darzustellen. Syntax ist ein Mittel, um String-Daten darzustellen.

Daher denke ich, dass das folgende Verhalten gestoppt werden sollte: "Wenn es logisch weniger ist, warum gibt es dann eine if-Anweisung? HA-HA, Schachmatt!!!"

Dann ändern Sie es in "{{#exists}}" anstelle von "{{#if}}", weil das sinnvoller ist.

Am 5. Oktober 2013 um 10:52 Uhr schrieb cal127 [email protected] :

Ich glaube, dass Sie ein einzelnes if/es sei denn (ohne Bedingungen) einfach nicht als Logik betrachten können, da es nur - im logiklosen Kontext - ein Mittel ist, um boolesche Daten als "{{foo}}" darzustellen. Syntax ist ein Mittel, um String-Daten darzustellen.

Daher denke ich, dass das folgende Verhalten gestoppt werden sollte: "Wenn es logisch weniger ist, warum gibt es dann eine if-Anweisung? HA-HA, Schachmatt!!!"

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

:thumbsup: zum Ändern von {{#if}} in {{#exists}} oder {{#isTrue}}

Ich stimme zu, dass wir einen vernünftigeren Namen finden können. 'existiert' würde es tun, und meine Vorschläge wären 'true' oder 'on'.

Dennoch wäre der Name „wenn“ aus historischen Gründen immer noch passender. Die if-Implementierung von Handlebars unterscheidet sich syntaktisch nicht von jeder anderen if-Implementierung, sie entspricht der alten Syntax "if ([Prädikat]) [do sth]".

Der Unterschied besteht darin, dass das [Prädikat] eine bloße boolsche Variable sein muss, es kann kein Ausdruck sein. Aber das ist nicht die Einschränkung von 'if'. Dies ist eine allgemeinere Einschränkung, die durch fehlende Unterstützung für Ausdrücke des Handlebars-Interpreters verursacht wird. (Das ist genau das, was Lenker übrigens logisch weniger macht, denke ich)

Das bedeutet, dass sich dieses „Wenn“ nicht von jedem anderen „Wenn“ unterscheidet.

Und der Versuch, den Namen von 'if' zu ändern, mag von manchen als Ketzerei angesehen werden, sagen Sie nicht, ich hätte Sie nicht gewarnt.

Nennen Sie es {{#truthy}} und {{#falsey}} denn das ist alles, was {{#if}} und {{#unless}} tun.

An die Entwickler: Holt den Kopf aus dem Sand. Ernsthaft. Sie können sehen, dass eine richtige if-Anweisung verlangt wird (und ich beabsichtige, das Wort 'Nachfrage' ganz wörtlich zu verwenden), also gehen Sie und implementieren Sie sie, anstatt über Logiklosigkeit zu jammern. Wenn Sie möchten, dass Ihre Vorlagen logisch sind, entfernen Sie ALLE Logik, einschließlich {{#if}} und {{#each}} .

Implementieren Sie NUR eine richtige if-Anweisung.
Leute, die fest an ihre Logiklosigkeit glauben, sollten sich dafür entscheiden, sie nicht zu verwenden. Einfach. Wie. Dass.

Ich habe die Arbeit sogar schon für dich erledigt.

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

Am 5. Oktober 2013 um 15:20 Uhr schrieb thany [email protected] :

Nennen Sie es {{#truthy}} und {{#falsey}}, denn das ist alles, was {{#if}} und {{#unless}} tun.

An die Entwickler: Holt den Kopf aus dem Sand. Ernsthaft. Sie können sehen, dass eine richtige if-Anweisung verlangt wird (und ich beabsichtige, das Wort 'Nachfrage' ganz wörtlich zu verwenden), also gehen Sie und implementieren Sie sie, anstatt über Logiklosigkeit zu jammern. Wenn Sie möchten, dass Ihre Vorlagen logisch sind, entfernen Sie ALLE Logik, einschließlich {{#if}} und {{#each}}.

Implementieren Sie NUR eine richtige if-Anweisung. Leute, die fest an ihre Logiklosigkeit glauben, sollten sich dafür entscheiden, sie nicht zu verwenden. Einfach. Wie. Dass.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

Danke dafür, aber die Lösung sollte im Kernpaket enthalten sein. Der Begriff "ifTest" kommt vermutlich nur daher, weil Handlebars den Begriff "if" kapert, bevor Sie ihn verwenden können.

Eine andere Sache ist, dass Ihr ifTest einen String nimmt und diesen String zur Laufzeit auswertet Punkte - einen, den ich nicht gerne über Bord werfe, indem ich eval() für ifs und elses verwende)

Du hast 100% Recht. Nur mit den mir damals zur Verfügung stehenden Tools.

Egal, es funktioniert.

Am 5. Oktober 2013 um 15:41 Uhr schrieb thany [email protected] :

Danke dafür, aber die Lösung sollte im Kernpaket enthalten sein. Auch der Begriff "ifTest" kommt vermutlich nur daher, weil Handlebars den Begriff "if" kapert, bevor Sie ihn verwenden können. Eine andere Sache ist, dass Ihr ifTest einen String nimmt und diesen String zur Laufzeit auswertet Punkte - eine, die ich nicht gerne über Bord werfe, indem ich eval () für ifs und elses verwende)

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

Ich bin gerade über diesen Thread gestolpert, als ich nach einem Vergleich in Lenker gesucht habe. Ich denke, Sie sollten entweder die Blöcke {{#if}} und {{#each}} entfernen / umbenennen oder eine richtige if-Anweisung implementieren. Es ist eine grundlegende Funktion für jede Sprache. Zeitraum. Wenn Sie wirklich logische Vorlagen haben möchten, warum verwenden Sie nicht stattdessen einfach Moustache?

Ich verstehe, dass es unter Entwicklern die Meinung gibt, dass Vorlagen von Nicht-Entwicklern (dh Designern) gelesen werden sollten. Aber A) Ich habe noch nie mit einem Designer zusammengearbeitet, bei dem dies ein Problem war, und B) Ich denke, der Ansatz sollte darin bestehen, dass eine generische Lösung integriert verfügbar ist, und als Erweiterung können Sie die boolesche Prüfung verwenden, also haben Sie eine Wahl. Außerdem werden Sie durch das Hinzufügen von Helfern wie {{#ifValueEqualsA}} und {{#ifValueEqualsB}} gezwungen, eine Menge Boilerplate-Code zu erstellen, der einfach nicht benötigt wird. Ich arbeite in einem nicht so großen mobilen Projekt und habe bereits 200 Zeilen Code, die nur Vergleiche für spezifische Anforderungen hinzufügen. Das widerspricht (hoffentlich) jeder Entwickler-Mentalität, dass die Dinge so allgemein wie möglich sein sollten.

@cal127 "Ich glaube, dass Sie ein einzelnes Wenn / Es sei denn (ohne Bedingungen) einfach nicht als Logik betrachten können" - Was ist dann das Problem? Warum ist die Prüfung eines Ausdrucks logischer als die Prüfung eines booleschen Werts? Es ist ein Scheck. Zeitraum. Das ist die Logik, die hier gemacht wird, nicht der Ausdruck (da ein boolescher Wert – raten Sie mal – ein Ausdruck ist). Vorausgesetzt natürlich, der Ausdruck repräsentiert keine Geschäfts-, sondern UI-Logik.

Es tut mir leid, dass die Idee von logiklosen Template-Engines bereits im Sterben liegt ... ich sehe nicht, dass dies in Zukunft noch weitergeht. Entwickler brauchen Tools, die Dinge einfacher und schneller machen, nicht komplizierter.

@thany rockt. Ich kam gestern über Schnurrbart (eine andere logiklose Vorlage lang) und genau diese Frage tauchte wenige Augenblicke später in meinem Kopf auf. Wie haben Programmierer das jemals für cool gehalten? Dies macht die Sache nur noch schlimmer. Programmierparadigma, das ich kenne, ist "Trennung der GESCHÄFTS-Logik von der PRÄSENTATIONS-Logik". Das bedeutet def, dass es eine Logik in der Präsentation gibt (Ansichten, die Vorlagen in einem Muster wie z. B. mvc enthalten/einschließen). Wie kommt es, dass sie versuchen, dies zu negieren und die Logik aus der Präsentation zu entfernen.

Szenario: Ich führe eine Schleife in einer Ansicht aus und möchte nach x Iterationen eine Aktion ausführen. Beim Lenker muss ich jetzt mal einen Helfer erstellen und dann in der Schleife verwenden, oder? wie erleichtert das mein leben? Was ist passiert, wenn count==x??? Wie ist das besser, als eine Sprache wie PHP selbst für Ihre Vorlagen zu verwenden? Wie hilft es beim Design über logische Template-Engines?

Mir? Nichts ohne Logik für einen logikorientierten Job. Es tut uns leid!

Ich kann nicht glauben, wie unwissend Sie sein können, liebe Gläubige der Logiklosigkeit. Es ist einfach keine Realität, es ist ein kompletter Mythos, ein Trugschluss, eine falsche Religion. Keine Vorlage mit mehr als ein paar Zeilen wird jemals völlig logisch sein. Es ist einfach nicht praktikabel.

Nun liegt es ganz bei Ihnen, Ihren Benutzern eine solche Überzeugung aufzuzwingen. Aber immer wieder jede Forderung nach Logik abzutun, ist ein Beweis für Dummheit und Ignoranz. Vor allem in diesem speziellen Fall, da schon eine Menge Logik möglich ist, wenn auch winzig.

Auch hier fordere ich Sie dringend auf, es sich noch einmal zu überlegen. Nein, warte, überlege es dir nicht noch einmal. Hören Sie einfach zu und tun Sie das Richtige. Leute, die keine dieser albernen Logiken in ihren Vorlagen haben wollen, können ihre bösen Wege fortsetzen und durch alle Arten von Reifen springen, um keine Logik zu verwenden.

Das Erweitern des if-Blocks, um richtige Vergleiche durchzuführen, nimmt seine aktuelle Verwendung nicht weg. Es wird denen, die das logische Licht noch nicht gesehen haben, keine Schwierigkeiten bereiten, diese Leute können weiterhin so codieren, wie sie waren.

Es geht nicht um cool; Sie selbst verwenden die Trennung von Logik und Präsentation als Argument und ignorieren sie dann, um eine Vereinfachung Ihres Lebens zu fordern. Sie hätten Ihrem Projekt jede der Standard-Lenkervorlagenbibliotheken hinzufügen oder Ihre eigenen schreiben können.

Sie oder sonst niemand hat eines der zahlreichen Argumente dagegen in einem der zahlreichen Threads angesprochen. Nur damit diese Argumente in diesem Thread klar sind:
1) Sie stören ein bestehendes Ökosystem; Dies führt zu Konflikten und Überarbeitungen für Teams, die aktualisieren möchten, aber seit ~ 2 Jahren ihre eigene IF haben.
2) Es gibt vorhandene Hilfsbibliotheken, die die bei Bedarf hinzufügen, zusammen mit allen anderen Hilfsprogrammen, nach denen Sie als nächstes fragen werden.
3) Sobald vereinbart ist, dieses „wenn“ hinzuzufügen, wird das neue Argument die Umsetzung sein. Name. Syntax. Argumente. Sie können versprechen, mit dem zufrieden zu sein, wenn das auftaucht, aber andere werden es nicht tun. Es wird hier sofort einen oder mehrere neue Threads geben, in denen argumentiert wird, dass es anders funktionieren sollte.
4) Das vorhandene 'Wenn' ist genau das, was zum -Rendering- da sein sollte. "X anzeigen, wenn Y vorhanden ist". Es geht nicht um Geschäftslogik; was in Ihrem Modell passieren sollte (ich schlage Backbone vor, dann können Sie alles haben, was Sie wollen, um nur eine isXXX()-Methode in Ihrem Modell zu sein).

Da wir uns gegenseitig um Dinge bitten, setzen Sie dies bitte nicht fort, wenn Sie kein ziemlich gutes technisches Argument für eine größere Änderung haben. Frustriert zu sein ist albern - Fügen Sie das gewünschte "WENN" hinzu und fertig.

1) Nein, das wirst du nicht. Wenn Sie nichts tun, sollten die Vorlagen weiterhin funktionieren. Natürlich sollte alles abwärtskompatibel sein. Und selbst wenn dies nicht der Fall ist, aktualisieren Sie einfach nicht.
2) Eine if-Anweisung ist elementar. Was Sie sagen, ist, dass Räder an einem Auto jetzt optional sind.
3) Die Syntax einer if-Anweisung ist von sehr geringer Bedeutung. Jede einzelne Programmiersprache hat eine und jede von ihnen macht genau das gleiche. Also wähle einen aus und alles wird gut. Noch wichtiger ist, dass JEDE richtige if-Anweisung besser ist als das, was wir jetzt haben.
4) Falsch, suchen Sie nach oben nach "Vorlagenlogik".

Was Ihre letzte Haltung angeht, das Argument ist _has_ vorgebracht worden, und es ist stichhaltig. Es wurde immer wieder darüber gestritten, aber es scheint wirklich eine Religion zu sein. Unzerbrechlich und doch so zerbrechlich.

George Frick-

1) Inwiefern unterscheidet sich dies vom Upgrade JEDES anderen Frameworks oder einer Bibliothek, die jemals existiert hat?
2) Du hast Recht. Das manuelle Hinzufügen dieser grundlegenden Funktionen sollte jedoch für etwas so Grundlegendes und Notwendiges nicht erforderlich sein.
3) Dafür sind Pull Requests da.
4) Du hast den Punkt völlig verfehlt. Niemand in diesem Thread argumentiert für die Geschäftslogik in der Ansichtsebene. Wir argumentieren für eine NÜTZLICHE Anzeigelogik in der Ansichtsebene. Das angegebene "Wenn" ist kein wahres Wenn, was es für jeden verwirrend macht, der jemals eine Programmiersprache verwendet hat. Es ist eher ein "existiert".

Wenn Sie der Meinung sind, dass das Hinzufügen dieser Informationen dazu führen würde, dass Benutzer Geschäftslogik in Vorlagen verwenden, haben Sie wahrscheinlich Recht, da Sie dummes nicht reparieren können. Nur weil jemand etwas Schlechtes tun KANN, heißt das nicht, dass Sie andere daran hindern sollten, dabei etwas Gutes (und Notwendiges) zu tun.

Am 22. November 2013 um 15:55 Uhr schrieb George Frick [email protected] :

Es geht nicht um cool; Sie selbst verwenden die Trennung von Logik und Präsentation als Argument und ignorieren sie dann, um eine Vereinfachung Ihres Lebens zu fordern. Sie hätten Ihrem Projekt jede der Standard-Lenkervorlagenbibliotheken hinzufügen oder Ihre eigenen schreiben können.

Sie oder sonst niemand hat eines der zahlreichen Argumente dagegen in einem der zahlreichen Threads angesprochen. Nur damit die Argumente in diesem Thread klar sind:
1) Sie stören ein bestehendes Ökosystem; Dies führt zu Konflikten und Überarbeitungen für Teams, die aktualisieren möchten, aber seit ~ 2 Jahren ihre eigene IF haben.
2) Es gibt vorhandene Hilfsbibliotheken, die die bei Bedarf hinzufügen, zusammen mit allen anderen Hilfsprogrammen, nach denen Sie als nächstes fragen werden.
3) Sobald vereinbart ist, dieses „wenn“ hinzuzufügen, wird das neue Argument die Umsetzung sein. Name. Syntax. Argumente. Sie können versprechen, mit dem zufrieden zu sein, wenn das auftaucht, aber andere werden es nicht tun. Es wird hier sofort einen oder mehrere neue Threads geben, in denen argumentiert wird, dass es anders funktionieren sollte.
4) Das vorhandene 'Wenn' ist genau das, was zum -Rendering- da sein sollte. "X anzeigen, wenn Y vorhanden ist". Es geht nicht um Geschäftslogik; was in Ihrem Modell passieren sollte (ich schlage Backbone vor, dann können Sie alles haben, was Sie wollen, um nur eine isXXX()-Methode in Ihrem Modell zu sein).

Da wir uns gegenseitig um Dinge bitten, setzen Sie dies bitte nicht fort, wenn Sie kein ziemlich gutes technisches Argument für eine größere Änderung haben. Frustriert zu sein ist albern - Fügen Sie das gewünschte "WENN" hinzu und fertig.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

@thany
Es gibt einen Unterschied zwischen dem Widerlegen eines Arguments und dem Zurückweisen eines Arguments. "FALSCH" entspricht "NUH UH!".
Versuchen Sie auch, nicht so persönlich zu sein.

@tniswong
1) Ist es nicht, das gleiche gilt in jedem Rahmen.
2) Wenn Sie dies im Allgemeinen anwenden, sollte Node alle seine Komponenten umfassen. Dass sie grundlegend oder notwendig sind, kann argumentiert werden, würde aber zu der Idee führen, dass es eine gute Abstraktion und Trennung ist, sie alle außerhalb des Standardrahmens zu gruppieren. Viele Projekte brauchen einfach keine davon, andere brauchen spezielle Versionen. Sie können also ein Standardset hinzufügen, Ihr eigenes schreiben oder keines verwenden. Es gibt (wieder) keinen technisch vernünftigen Grund dafür, dass all diese Helfer standardmäßig eingerollt werden.
3) Ihre Aussage negiert in der Tat in keiner Weise den ursprünglichen Punkt - Sie helfen ihm. 20 Pull-Requests, um If zu beheben. Ich wette, das Entwicklerteam wird es lieben, sie durchzugehen.
4) Genau, es ist ein 'existiert'. Rendern Sie dies, falls vorhanden.
Wenn Sie nicht über „jemanden jemals“ schreiben können, braucht es ein einziges Gegenbeispiel. _erhebt die Hand_.

Aus den obigen Notizen scheint mir eines der folgenden erforderlich zu sein:

1. Benennen Sie if in exists und hören Sie auf, Lenker "logiklos" zu nennen (weil dies nicht der Fall ist)
2. Fügen Sie Unterstützung für if um sich wie eine if Anweisung zu verhalten.
3. Entfernen Sie if vollständig.

Ich würde mich über eine dieser Optionen freuen.

Nicht vergessen {{#unless}}

Am 22. November 2013 um 16:40 Uhr schrieb Aaron M [email protected] :

Aus den obigen Notizen scheint mir eines der folgenden erforderlich zu sein:

Benennen Sie if to exist um und hören Sie auf, Lenker "logiklos" zu nennen (weil dies nicht der Fall ist)
Fügen Sie Unterstützung für if hinzu, um sich wie eine if-Anweisung zu verhalten.
Entfernen Sie, wenn vollständig.
Ich würde mich über eine dieser Optionen freuen.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

Ich denke, worauf es wirklich hinausläuft, wird von Aaron gut zusammengefasst.

1. Es gibt eine Heuchelei, die angegangen werden muss, indem behauptet wird, logisch weniger zu sein UND ein Wenn / Es sei denn.
2. Das angegebene "if" ist eine falsche Bezeichnung.

Beheben Sie beide, und dieses Argument verschwindet.

Am 22. November 2013 um 16:43 Uhr schrieb Todd Niswonger

Nicht vergessen {{#unless}}

Am 22. November 2013 um 16:40 Uhr schrieb Aaron M [email protected] :

Aus den obigen Notizen scheint mir eines der folgenden erforderlich zu sein:

Benennen Sie if to exist um und hören Sie auf, Lenker "logiklos" zu nennen (weil dies nicht der Fall ist)
Fügen Sie Unterstützung für if hinzu, um sich wie eine if-Anweisung zu verhalten.
Entfernen Sie, wenn vollständig.
Ich würde mich über eine dieser Optionen freuen.

—
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an.

@georgfrick
Ich habe sein Argument zurückgewiesen, nur weil es schon millionenfach widerlegt wurde. Wir haben das viel zu lange hinter uns, und es muss ein Ende haben. Die if-Anweisung muss hinzugefügt werden, niemand wird benachteiligt und alle werden glücklich sein. Nicht in ALLEN Häusern eine Klimaanlage zu wollen ist dasselbe. Ich werde der Richter sein, was ich in meinem Haus will. Wenn es in deinem ist und du es nicht willst, dann lass es sein. So einfach ist das.

@webgovernor
Es muss keine Umbenennung vorgenommen werden. Eine richtige if-Anweisung kann mit der aktuellen vollständig kompatibel gemacht werden. Derzeit ist es nur "if boolean then...", und jede voll funktionsfähige if-Anweisung wird genau das tun, nur dieses boolesche Ding kann jetzt ein beliebiger Ausdruck sein und nicht nur eine Variable.

@tniswong
Wie nett von ihnen, oder? Um ein schmutziges zusätzliches Tag hinzuzufügen, weil der if-Block, wie er implementiert wurde, so stark vereinfacht ist, dass er nicht einmal einen Ausdruck negieren kann. Aber in einem zukünftigen Handlebars kann das else-Tag einfach ein Alias ​​für "wenn nicht" werden. Ein bisschen wie do..while versus while..do in der Programmierung, wo die beiden hauptsächlich aus Gründen der Lesbarkeit existieren und nicht _wirklich_ aus technischen Gründen.

Auch ich wünsche mir grundlegende Vergleiche bei Lenkern. Ich verstehe die logische Philosophie. Ich glaube auch, dass grundlegende Vergleichsunterstützung intuitiver wäre und Benutzern ein effizienteres Arbeiten ermöglichen würde. Wenn Benutzer in der Masse die grundlegende Vergleichslogik auf einen Helfer übertragen, tut ihnen diese Philosophie keinen Gefallen oder schreckt sie von einem wahrgenommenen suboptimalen Verhalten ab – sie schafft nur mehr Arbeit.

@jeremiahlee Ich bin mir nicht sicher, ob du mir da

Wie auch immer, ich habe in der Vergangenheit mit Handlebars gearbeitet und sie gebeten, einen richtigen if-Block zu implementieren. Dies führte zu einer Lawine von Kommentaren über eine falsche Philosophie, dass Logik im Modell bleiben sollte. Kein Handlebars-Entwickler wollte auch nur einen Millimeter außerhalb seiner eigenen winzigen Welt denken (es gibt ein unhöfliches Wort dafür, aber ich überspringe es). Schau dir einfach diesen Thread als Beweis an.

Dies zwang mich, einen Helfer namens "when" zu schreiben, der Vergleiche anstellt. Noch keine richtige Wenn-Block-Konstruktion, aber für mich damals nah genug. Es hat mir aber viel unnötige Arbeit gemacht.

@thany : Ich stimme zu, dass Lenker einen grundlegenden Vergleich von zwei Werten eingebaut haben sollten. Logische Vorlagen sollten nicht auch empathielos sein.

Ich werde auch für @thany und die anderen Argumente stimmen. Die if else Anweisungen sind viel zu einfach.
Bedingte Klassen und select Boxen mit vorausgewählten option s sollten mit dem Standardpaket von Lenkern machbar sein.

Mit verschachtelten Helfern ist das kein Thema mehr, zB

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

gutes Beispiel @mmun :+1:

Ein bisschen seltsam, und ich sehe keine booleschen Kombinatoren... Aber vor allem ändert es nicht den Gesamtstandpunkt der Betreuer dieses Projekts, das ein unzerbrechliches "NO LOGIC!!11!! 1!1" Ansicht.