Handlebars.js: ne peut pas utiliser une chaîne d'entier comme identifiant

Créé le 27 juin 2011  ·  10Commentaires  ·  Source: handlebars-lang/handlebars.js

Ce sont mes premières heures de travail avec Handlebars, donc j'ai peut-être raté quelque chose, mais.....

Avec des données comme celle-ci : {status : {"200": 4, "304": 10}}, il semble que l'on ne puisse pas accéder à ces entrées avec des représentations sous forme de chaîne d'entiers comme clés. Ce modèle ne fonctionne pas pour moi (en utilisant le package 1.0.3beta):

{{#avec statut}}
{{#if 200}} OK : {{ 200 }} {{/if}}
{{/avec}}

le {{ 200 }} entraîne une erreur d'analyse "EXPECTING ID". La même chose se produit lorsque le modèle contient : {{ "200" }}. Curieusement, le {{#if 200}} semble fonctionner correctement.

bug

Commentaire le plus utile

bon à savoir que les crochets aident comme solution de contournement, mais je voulais souligner que ce comportement rompt la compatibilité descendante avec la moustache.

J'avais des modèles de moustache où j'accédais aux éléments du tableau par des index littéraux en écrivant :

{{someArray.0}}

Cependant, lorsque j'ai essayé de migrer mon application de la moustache au guidon (en supposant que les modèles devraient tous fonctionner), je me suis retrouvé avec des tonnes d'erreurs

`En attente de 'ID', a 'INTEGER'``

Heureusement, changer ces expressions en

{{someArray.[0]}}

résolu le problème. cela vaut peut-être la peine d'étendre un peu le langage pour prendre en charge ces expressions pour la compatibilité avec la moustache.

Merci

Tous les 10 commentaires

Dans Handlebars, les entiers sont tokenisés en INTEGER. Vous pouvez faire fonctionner n'importe quelle séquence de caractères en les entourant entre parenthèses :

{{#with status}}
  {{#if [200] }} OK: {{ [200] }} {{/if}}
{{/with}}

bon à savoir que les crochets aident comme solution de contournement, mais je voulais souligner que ce comportement rompt la compatibilité descendante avec la moustache.

J'avais des modèles de moustache où j'accédais aux éléments du tableau par des index littéraux en écrivant :

{{someArray.0}}

Cependant, lorsque j'ai essayé de migrer mon application de la moustache au guidon (en supposant que les modèles devraient tous fonctionner), je me suis retrouvé avec des tonnes d'erreurs

`En attente de 'ID', a 'INTEGER'``

Heureusement, changer ces expressions en

{{someArray.[0]}}

résolu le problème. cela vaut peut-être la peine d'étendre un peu le langage pour prendre en charge ces expressions pour la compatibilité avec la moustache.

Merci

@santip je suis confus. Moustache ne prend pas du tout en charge les chemins, alors comment pourriez-vous faire {{someArray.0}} dans la moustache ?

aww, mon mauvais, ok, j'utilisais en fait hogan.js et je ne savais pas qu'il n'était pas pris en charge sur la moustache.

btw, lors de la migration de hogan.js, j'ai également remarqué que le bouillonnement ne semble pas fonctionner comme dans hogan (ou moustache):

Handlebars.compile('aaa {{a}} {{#b}}{{c}}{{d}}{{/b}}')({a:1, b:[{c:2}], d:3}) == 'aaa 1 2'

Hogan.compile('aaa {{a}} {{#b}}{{c}}{{d}}{{/b}}').render({a:1, b:[{c:2}], d:3}) == 'aaa 1 23'

Mustache.render('aaa {{a}} {{#b}}{{c}}{{d}}{{/b}}', {a:1, b:[{c:2}], d:3}) == 'aaa 1 23'

Cela fonctionne lorsque j'utilise ../ c'est la raison pour laquelle je suis passé à Handlebars mais j'ai pensé que cela valait la peine de souligner le manque de compatibilité là-bas.

De plus, je viens de tester la moustache et elle semble supporter les chemins

Mustache.render('aaa {{a}} {{b.c}}', {a:1, b:{c:2}, d:3}) == 'aaa 1 2'

Oui, la moustache supporte les chemins. Vérifiez les noms en pointillés dans https://github.com/mustache/spec/blob/master/specs/sections.yml

On dirait que la moustache a ajouté des fonctionnalités. Je ne sais pas si je me suis inscrit pour suivre la spécification Moustache pour toujours :/

Il ne semble pas que la spécification Moustache décrive le comportement de .<integer> . Je pourrais certainement faire en sorte que cela fonctionne, bien que le foo.[anything] Handlebars fonctionne mieux pour les chemins non-identifiants.

Mon plan initial était "s'il s'agit d'un chemin de points valide dans JS, cela fonctionne dans Handlebars".

Y a-t-il une raison pour laquelle vous ne pouviez pas prendre en charge la notation de chemin .<integer> ?

Je ne pense pas que vous devriez prendre en charge le bouillonnement car cela casserait probablement de nombreux modèles de guidons existants, bien que vous deviez probablement mettre à jour la documentation et le site pour informer de ces incompatibilités afin d'éviter des maux de tête aux personnes effectuant la migration.

J'ai rencontré cela en essayant d'utiliser des identifiants sous la forme {{1}} , qui se compilent bien dans Moustache et Hogan mais jettent Expecting 'ID', 'DATA', got 'NUMBER' dans Handlebars. Bien que j'aimerais que les entiers soient pris en charge, je comprends et supporte totalement l' approche

Cependant, je pense que les docs devraient refléter cela. Ils déclarent actuellement :

Identifiers may be any unicode character except for the following:
Whitespace ! " # % & ' ( ) * + , . / ; < = > @ [ \ ] ^ ` { | } ~

ce qui, je pense, est trompeur car les entiers ne sont pas valides. Il est beaucoup plus clair de dire "s'il s'agit d'un chemin de points valide dans JS, cela fonctionne dans Handlebars", comme suggéré.

http://handlebarsjs.com/expressions.html

Cette page vous a été utile?
0 / 5 - 0 notes