Angular.js: ngRépéter avec DL / DD / DT

seconde ceci. J'ai ce problème depuis un moment.

@IgorMinar a travaillé sur un ng-repeat basé sur les commentaires (https://github.com/angular/angular.js/pull/1646) mais comme les commentaires ne fonctionnent pas aussi bien sur tous les navigateurs, il est peu probable que ce soit le cas. fusionné. Au lieu de cela, ils recherchent une solution alternative, probablement avec "les balises de début et de fin de répétition" ou "la répétition de début et le nombre d'éléments pour répéter l'étiquette"

Que diriez-vous d'autoriser les modèles à l'intérieur de paires comme {{ }}

peut être:
{{! ng-repeat = "foo in l"

Sur une note connexe, j'ai un problème similaire avec Y aurait-il de grands défis techniques à un deuxième formulaire d'interpolation
comme {{{ }}} qui n'a pas échappé aux caractères html mais n'a pas non plus créé de
nouvelle travée ?

Le mar. 29 janv. 2013 à 12:38, Pete Bacon Darwin <
[email protected]> a écrit :

@IgorMinar https://github.com/IgorMinar a travaillé sur un
ng-repeat basé sur les commentaires (#1646https://github.com/angular/angular.js/issues/1646)
mais comme les commentaires ne fonctionnent pas aussi bien sur tous les navigateurs, il est peu probable que
être fusionné. Au lieu de cela, ils cherchent une solution alternative, probablement
avec soit « balises de début et de fin de répétition » ou « début-répétition et nombre de
éléments à répéter étiquette"

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/angular/angular.js/issues/1891#issuecomment -12856484.

Je viens de rencontrer ce problème avec une table qui veut générer deux éléments 'td' par objet dans un tableau.

+1 pour l'ajout de cette fonctionnalité. Je viens de rencontrer cette même limitation.

:pouces vers le haut:

Même problème ici. J'aimerais voir quelque chose comme "ng-repeat-children" ne répétant que les enfants mais pas l'élément actuel ou une sorte de "ng-omit-tag" (qui supprime la balise actuelle mais laisse les enfants en place) à utiliser avec ng-repeat. Cela éviterait des tonnes de balises non valides générées pour contourner ce problème.

Je ne comprends pas bien la limitation qui est en cours de discussion. Pourquoi mettre le ng-repeat sur l'élément parent fonctionne? http://jsfiddle.net/JyWdT/13/
Quelqu'un peut-il créer un violon qui explique le problème plus en détail ?

lgalfaso, Votre violon crée plusieurs listes de définitions chacune avec une définition. La sortie souhaitée est une liste de définitions avec plusieurs définitions.

Ou dans mon cas, je dois créer une paire d'éléments "td" pour chaque élément d'un tableau.
Disons que j'ai un tableau,

[{name:dan, age:15}, {name:steve, age:21}]

et j'ai besoin de sortir:

<tr><td>dan</td><td>15</td><td>steve</td><td>21</td></tr>

Il n'y a aucun moyen d'y parvenir avec angulaire pour le moment.

ne pouvez-vous pas le faire en mettant le ng-repeat sur l'élément tr?

http://plnkr.co/edit/lJvkOpz0NnKWcfEeM4lE?p=preview

Le dimanche 21 avril 2013 à 14h24, zilles [email protected] a écrit :

lgalfaso, Votre violon crée plusieurs listes de définitions chacune avec une
définition. Le résultat souhaité est une liste de définitions avec plusieurs
définitions.

Ou dans mon cas, je dois créer une paire d'éléments "td" pour chaque élément de
un tableau.
Disons que j'ai un tableau,

[{ name:dan , age:15 }, { name:steve , age:21 }]

et j'ai besoin de sortir:

dan15steve21

Il n'y a aucun moyen d'y parvenir avec angulaire pour le moment.

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/angular/angular.js/issues/1891#issuecomment -16716788
.

Oh, je vois, ne tenez pas compte de mon commentaire précédent
Le 21 avril 2013 à 9 h 09, " jason turim " jason. [email protected] a écrit :

ne pouvez-vous pas le faire en mettant le ng-repeat sur l'élément tr?

http://plnkr.co/edit/lJvkOpz0NnKWcfEeM4lE?p=preview

Le dimanche 21 avril 2013 à 14h24, zilles [email protected] a écrit :

lgalfaso, Votre violon crée plusieurs listes de définitions chacune avec une
définition. Le résultat souhaité est une liste de définitions avec plusieurs
définitions.

Ou dans mon cas, je dois créer une paire d'éléments "td" pour chaque élément de
un tableau.
Disons que j'ai un tableau,

[{ name:dan , age:15 }, { name:steve , age:21 }]

et j'ai besoin de sortir:

dan15steve21

Il n'y a aucun moyen d'y parvenir avec angulaire pour le moment.

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/angular/angular.js/issues/1891#issuecomment -16716788
.

Comme je viens de rencontrer le problème dl / dt + dd, je confirme qu'un nouveau ng-repeat-children (ou ng-repeat-inner) est une directive obligatoire manquante.

+1

Proposition de nouvelle directive ng-repeat-inner. Si cette proposition est ok, alors modifiera tous les guides

Je pense qu'il serait préférable d'utiliser la même directive ng-repeat , mais autoriser l'utilisation de cette directive sur les commentaires HTML, comme le suggère le message original.

Quelque chose comme ceci devrait alors fonctionner :

<dl>
  <!-- ng-repeat="(name, definition) in myList" -->
  <dt>{{name}}</dt>
  <dd>{{definition}}</dd>
  <!-- /ng-repeat -->
</dl>

Je ne sais pas exactement comment le début et la fin du bloc à répéter seraient obtenus ( <!-- /ng-repeat --> été suggéré par @ProLoser), mais je pense que l'utilisation de commentaires HTML serait une solution élégante.

Étant donné que les minificateurs peuvent tuer les commentaires et autres problèmes avec les commentaires, je
ne pense pas que ce soit génial. Cependant, j'aime l'idée d'utiliser ng-repeat.
serait-il possible d'inclure un attribut ng-repeat-single-root ou
quelque chose qui, lorsqu'il est défini sur true, exécutera le ng-repeat sans la racine
élément? Par exemple:

{je}

{je}

deviendrait:

1

1

2

2

3

3

Le Mar 23 Avr 2013 à 15h54, Mani Tadayon [email protected] a écrit :

Je pense qu'il serait préférable d'utiliser la même directive ng-repeat, mais permettez
pour que cette directive soit utilisée sur les commentaires HTML, comme le message d'origine
suggère.

Quelque chose comme ceci devrait alors fonctionner :

{{Nom}}

{{définition}}

Je ne sais pas exactement comment répéter le début et la fin du bloc
serait atteint (j'ai fait ledans mon exemple),
mais je pense que l'utilisation de commentaires HTML serait une solution élégante.

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/angular/angular.js/issues/1891#issuecomment -16891970
.

maxcan, je peux voir les avantages de "single-root", puisque vous gardez la source html valide, mais cette construction ne vous permet pas d'ajouter autre chose à l'intérieur de la balise "dl" ... Une définition fixe par exemple que vous voulez à inclure avant votre boucle de définitions dynamiques. La solution de lgalfaso s'occuperait de cela.

@maxcan sans une grosse

J'aime la suggestion de @bowsersenior , mais je préférerais ceci comme commentaire de clôture : <!-- /ng-repeat -->

C'est une honte sur la performance hit. En tout cas, j'approuve fortement
La solution de @lgalfaso , en supposant que vous puissiez mettre la directive dans un div et non
juste un commentaire..

Le mer. 24 avril 2013 à 13:58, Dean Sofer [email protected] a écrit :

J'aime la suggestion de @bowsersenior https://github.com/bowsersenior , mais
Je préférerais ceci comme commentaire de clôture:

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/angular/angular.js/issues/1891#issuecomment -16964155
.

Je suis d'accord avec @ProLoser que <!-- /ng-repeat --> est une meilleure balise de fermeture dans l'approche de commentaire HTML. Une note, angulaire permet de définir des directives dans les commentaires HTML, donc je ne pense pas que les commentaires HTML puissent être rejetés comme une solution potentielle à ce problème. Gardez à l'esprit que les principaux développeurs angulaires ont indiqué qu'ils prévoyaient d'utiliser des commentaires HTML pour résoudre ce problème dans cette question de débordement de pile (comme l'a souligné l'affiche originale) :

• http://stackoverflow.com/a/10458127/457819

Cela ne me dérange pas de les jeter tant qu'il y a un moyen de le faire sans
commentaires.

Le mer. 24 avril 2013 à 14:41, Mani Tadayon [email protected] a écrit :

Je suis d'accord avec @ProLoser https://github.com/ProLoser qui est une meilleure balise de fermeture dans l'approche des commentaires HTML. Une
note, angulaire permet de définir des directives dans les commentaires HTML, donc je ne
pense que les commentaires HTML peuvent être rejetés comme une solution potentielle à ce problème
problème. Gardez à l'esprit que les principaux développeurs angulaires ont indiqué qu'ils
prévu d'utiliser des commentaires HTML pour résoudre ce problème dans ce débordement de pile
question (comme le souligne l'affiche originale) :

• http://stackoverflow.com/a/10458127/457819

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/angular/angular.js/issues/1891#issuecomment -16969268
.

+1 au ng-repeat-inner de @lgalfaso . J'aimerais enfin quelque chose qui fasse ça.

Knockout le fait avec des commentaires. J'essaie de porter quelque chose que j'ai fait avec la balise dl dans knockout et il semble que ce ne soit pas possible tant que ce problème n'est pas résolu.

C'est mon avis, donc sans l'apport de @mhevery ou @IgorMinar , prenez cela avec des
Je vois que faire fonctionner ng-repeat avec des commentaires est plus flexible, de toute façon. Cela ne semble pas naturel sans une modification de $compiler afin qu'il puisse gérer une directive de type "entre les commentaires". La raison en est qu'il semble étrange qu'une directive doive faire attention à l'imbrication et à l'extérieur de l'élément qui lui est donné pour faire ce qu'elle est censée faire

Si les commentaires/aucun commentaire sont à l'origine d'une controverse en cours, ne pouvons-nous pas simplement les avoir tous les deux ? J'ai du mal à comprendre qu'un problème aussi courant que celui-ci n'ait pas été traité depuis plus de 3 mois. Si la raison derrière cela est principalement due à une controverse sur la mise en œuvre, il semble plus préférable d'avoir quelque chose de réellement mis en œuvre (et peut-être mis à jour/ajouté à l'avenir) que d'attendre plus longtemps sans rien pour quelque chose de plus "optimal".

Dans la plupart des cas cependant, il me semble que si ng-repeat-inner fait référence à la répétition d'un ensemble d'éléments "à l'intérieur" d'un certain quelque chose, cela implique que dans la plupart des cas, vous avez déjà créé un conteneur externe exclusif de quelque sorte. Par conséquent, bien qu'une implémentation de commentaire puisse être plus polyvalente (bien que peut-être une demi-ligne de code supplémentaire que j'aimerais éviter si possible), je pense qu'elle peut être moins utilisée (et peut-être devrait-elle être moins prioritaire) que une directive dans l'élément.

La question de savoir s'il faut utiliser les commentaires HTML n'a aucun rapport avec le fait que ce problème est en suspens depuis quelques mois. Je pense que tout ce qui est nécessaire est une certaine attention de la part des mainteneurs angulaires pour décider du problème et mettre en œuvre une solution.

Au cas où vous l'auriez manqué, voir ici https://github.com/angular/angular.js/pull/1646 concernant les problèmes avec les répéteurs basés sur les commentaires. La solution

Merci d'avoir signalé #1646 . Il y a un commentaire dans cette discussion par @mhevery qui propose "une meilleure façon de le faire" sans montrer de code (probablement une erreur de formatage):

J'aimerais que nous sachions ce qu'était cette "meilleure façon" !

Le consensus au sein de l'équipe principale est qu'actuellement, la meilleure façon d'aborder ce problème est l'une des suivantes (nous n'avons pas encore réglé la syntaxe mais l'implémentation est presque la même pour tous) :

tous ces exemples contiennent deux balises td , je l'ai fait exprès même si c'est illégal car je voulais montrer que le répéteur devrait permettre de répéter sur un nombre arbitraire d'éléments - il serait préférable de convertir ces exemples en table d'utilisation et les lignes du tableau, mais je suis sur le point de me déconnecter maintenant et je n'ai pas le temps de les refactoriser.

Syntaxe A :

<dl>
  <dt ng-repeat="(name, definition) in myList">{{name}}</dt>
  <dd ng-repeat-next>{{definition}}</dd>
  <dd ng-repeat-next>{{definition}}</dd>
</dl>

Syntaxe B :

<dl>
  <dt ng-repeat-start="(name, definition) in myList">{{name}}</dt>
  <dd>{{definition}}</dd>
  <dd ng-repeat-end>{{definition}}</dd>
</dl>

Syntaxe C :

<dl>
  <dt ng-repeat="(name, definition) in myList" ng-repeat-start>{{name}}</dt>
  <dd>{{definition}}</dd>
  <dd ng-repeat-end>{{definition}}</dd>
</dl>

Syntaxe D :

<dl>
  <dt ng-repeat="(name, definition) in myList" ng-repeat-group>{{name}}</dt>
  <dd ng-repeat-group>{{definition}}</dd>
  <dd ng-repeat-group>{{definition}}</dd>
</dl>

À long terme, une fois que nous aurons une meilleure prise en charge du navigateur, nous commencerons à utiliser le nouvel élément <template> qui nous permettra de faire simplement ceci :

Syntaxe X :

<template>
  <dl>
    <ng repeat="(name, definition) in myList">
      <dt>{{name}}</dt>
      <dd>{{definition}}</dd>
      <dd>{{definition}}</dd>
    </ng>
  </dl>
</template>

si quelqu'un veut créer un PR pour cette solution, il sera fusionné. De plus, si vous avez une préférence pour une syntaxe particulière, veuillez en parler.

Merci pour l'entrée. De mon point de vue, la syntaxe A n'est pas claire pour les boucles imbriquées comme la suivante

<dl>
  <dt ng-repeat="...">loop 1</dt>
  <dt ng-repeat="..." ng-repeat-next>loop 2</dt>
  <dd ng-repeat-next>is this within loop 2 or only loop 1</dd>
</dl>

Les syntaxes B et C sont à peu près les mêmes, j'aime les deux alternatives (même quand je pense que la syntaxe B est en quelque sorte meilleure)

À moins que je manque quelque chose, la syntaxe D a les mêmes problèmes de boucles imbriquées que la syntaxe A

J'opterais pour B si possible, uniquement parce qu'il faut écrire le moins de lettres. Il semble également le plus symétrique - je pense que ce serait plus facile à gérer en raison de la symétrie visuelle.

Le commentaire de lgalfasos souligne un dilemme intéressant. Que faire si la boucle imbriquée dans son exemple est sur le premier élément au lieu du second. Ensuite, toutes les versions de la syntaxe ne sont plus claires, à moins que quelque chose ne me manque.

Je ne comprends pas très bien la différence entre le ng-repeat-inner proposé par @lgalfaso et le ng repeat dans la syntaxe X, bien que le <template> wrapping. Quelqu'un pourrait-il expliquer?

Je ne suis pas sûr de le comprendre non plus, mais je suppose que la balise <ng> ne fait pas partie du DOM, évitant ainsi une structure d'imbrication illégale sous dl .

Quant aux syntaxes proposées, je voterais pour B.

Je crois que le cas de la syntaxe X permet un élément d'emballage factice générique <ng> qui ne fait pas partie du DOM et peut héberger diverses directives. C'est plus générique que le ng-repeat-inner , qui ne s'applique qu'à un cas d'utilisation spécifique pour ng-repeat .

Si la syntaxe X, l'objectif à long terme, n'est qu'une version plus générique de ng-repeat-inner , je pense que ng-repeat-inner devrait également être (*pas seulement) adopté avec l'un des A,B proposés, C,D pour les éléments suivants :

1. la syntaxe X et ng-repeat-inner ont la même structure dom
   : si la syntaxe X est l'objectif à long terme, ce serait bien d'avoir quelque chose maintenant qui s'aligne de la même manière sur le plan de la structure pour empêcher une future refactorisation.
2. dans la plupart des cas, ng-repeat-inner suffirait de toute façon
   : l'intention est de créer un conteneur externe pour répéter les éléments internes.

@daegon123 la différence entre l'une des syntaxes répertoriées de @IgorMinar (y compris X) et ng-repeat-inner est que les syntaxes vous permettent de répéter arbitrairement un ensemble d'éléments sans conteneur distinct. Par exemple, répétez un ensemble de <tr> alors qu'il y a d'autres <tr> non répétitifs dans table ou tbody . Dans ce cas, les éléments à répéter n'ont pas de parent distinct auquel lier ng-repeat-inner .

<table>
    <thead>...</thead>
    <tr ng-repeat-start="(name, definition) in myList">...</tr>
    <tr>...</tr>
    <tr ng-repeat-end>...</tr>
    <tr>...</tr>
    <tfoot>...</tfoot>
</table>

Ou plusieurs définitions par objet dans un <dl>

<dl>
    <dt ng-repeat-start="...">{{item.term1}}</dt>
    <dd>{{item.def1}}</dd>
    <dt>{{item.term2}}</dt>
    <dd>{{item.def2}}</dd>
    <dt>{{item.term3}}</dt>
    <dd ng-repeat-end>{{item.def3}}</dd>
</dl>

@es128 Merci pour les commentaires et le code. C'est exactement la raison pour laquelle j'ai proposé que ng-repeat-inner soit accepté "avec" l'une des autres syntaxes répertoriées, mais voir le code réel dans vos commentaires a commencé à me faire me demander si ng-repeat-inner est même nécessaire. Je posterai un autre commentaire si je tombe sur quelque chose - merci encore !

Le problème avec ng-repeat-inner est qu'il ne peut pas être utilisé dans tous les cas, par exemple :

<ul>
  <li>some static prefix item</li>
  <!-- repeat these nodes -->
    <li>{{ something }}</li>
    <li>{{ something else }}</li>
  <!-- repeat end -->
  <li>some static postfix item</li>
</ul>

parce que vous ne pouvez pas mettre un élément artificiel (comme div) dans ul (par spécification html), ng-repeat-inner ne peut pas être utilisé ici.

d'ailleurs avec l'élément template, nous pourrons mettre un élément artificiel entre ul et li.

Aussi, ne vous attachez pas trop à la syntaxe X, c'était juste un exemple rapide et sale de ce que nous serons finalement capables de faire la syntaxe exacte n'est pas encore discutée, mais pendant que j'y suis, voici un autre une:

Syntaxe Y :

<ul>
  <li>some static prefix item</li>
  <template repeat="item in items">
    <li>{{ item.name }}</li>
    <li>{{ item.owner }}</li>
  </template>
  <li>some static postfix item</li>
</ul>

Qu'en est-il de la définition d'un identifiant sur le groupe ng-repeat ?
Ensuite, nous pouvions librement y attacher des objets à partir de n'importe quel niveau. Quelque chose comme

<dl>
    <dt ng-repeat="item in items" ng-repeat-group="someId">{{item.term}}</dt>
    <dd ng-repeat-with="someId">{{item.definition}}</dd>
</dl>

pourrait permettre la flexibilité dont nous avons besoin.

Implémentation proposée de la syntaxe C, il s'avère que je pense que c'est la syntaxe qui permettrait à ce même mécanisme d'être facile pour d'autres éléments et directives

Beau travail Lucas ! J'ai passé la soirée à essayer d'implémenter la syntaxe C. Cela fonctionne correctement, mais l'imbrication n'est pas prise en charge en raison de la transclusion qui transforme tous les ng-repeat en commentaires.

Si je ne peux pas traverser le DOM à la recherche de ng-repeat-start , je ne suis pas en mesure de calculer la profondeur de l'attribut ng-repeat-end pour la correspondance. Votre approche semble résoudre le problème...

Hmmm... quelque chose ne va pas. Des documents sont manquants dans votre commit, il se peut donc que je n'utilise pas la bonne syntaxe.

Jetez un œil à ceci :
http://plnkr.co/edit/sVilxKaNrhNM4JrkuQ5r?p=preview

Je m'attendais à ce que la sortie pour le cas non imbriqué soit :

Term: elastic
     Static term
     This definition should be repeated for every term: 'elastic' term
Term: par
     Static term
     This definition should be repeated for every term: 'par' term

Et pour l'imbriqué :

Term: elastic
     Static term
Subterm: superelastic
     Static subterm
     This should be repeater for every subterm: 'super' subterm from 'elastic' term
Subterm: subelastic
     Static subterm
     This should be repeater for every subterm: 'sub' subterm from 'elastic' term
     This definition should be repeated for every term: 'elastic' term
Term: par
     Static term
Subterm: superpar
     Static subterm
     This should be repeater for every subterm: 'super' subterm from 'par' term
Subterm: subpar
     Static subterm
     This should be repeater for every subterm: 'sub' subterm from 'par' term
     This definition should be repeated for every term: 'par' term

J'ai raté quelque chose ?

@lrlopez L'exemple que vous mettez n'utilise pas la dernière version du code. De plus, il y a un </dl> supplémentaire à la ligne 23

Merci pour cette réponse rapide! Vous avez raison, il y avait un </dl> supplémentaire à la ligne 23. J'ai également mis à jour la bibliothèque. Néanmoins, je n'arrive toujours pas à travailler l'exemple imbriqué...

Ok, il semble que ce soit un vrai problème avec les directives multi-éléments qui sont au même niveau dans le DOM. Mise à jour du PR avec un correctif pour ce problème

Des correctifs tels que ng-repeat-inner ou ng-repeat-next ne résolvent qu'une des innombrables situations où les comportements de liaison aux nœuds DOM réels vous limiteront.

Au lieu de corriger chaque directive individuellement, vous pouvez résoudre ce problème pour l'ensemble du framework en ajoutant la prise en charge des nœuds virtuels qui ne s'affichent pas dans l'arborescence réelle.

L'idée d'utiliser des commentaires est similaire, mais il en résulte un code inesthétique et difficile à lire et vous avez toujours besoin d'un moyen de nommer ce nœud et de le fermer d'une manière ou d'une autre. Au lieu d'inventer une nouvelle syntaxe de nœud de commentaire, utilisez la syntaxe HTML existante.

Considérez-le comme un concept similaire, disons, aux classes silencieuses SASS :

<div id="myComplexList">
    <ng-virtual ng-repeat="...">
        <a></a>
        <b></b>
        <c></c>
    </ng-virtual>
</div>

Result:

<div id="myComplexList">
    <a></a>
    <b></b>
    <c></c>
    <a></a>
    <b></b>
    <c></c>
    <a></a>
    <b></b>
    <c></c>
    ...
</div>

+1 à l'idée générale mais j'opterais pour quelque chose comme ng-repeat-group.

<ng-repeat-group="b in ches">
// group markup to be repeated here
</ng-repeat-group>

J'aime l'idée d'un nœud virtuel, mais je suis contre qu'il devienne une solution générale au problème ici.

Si possible, j'aimerais limiter la création de contenants artificiels. Bien que le conteneur puisse ne pas apparaître sur le code HTML du résultat global, il commencerait à encombrer le code HTML qui doit être géré.

Dans de nombreux cas, nous aurons besoin d'un conteneur pour contenir ce que nous voulons répéter. ex:

<tr>
  <td ng-repeat-start>1</td>
  <td ng-repeat-end>2</td>
</tr>

(le conteneur étant ici le [tr]s)

l'utilisation de la solution de nœud virtuel proposée transformerait cela en :

<tr>
  <ng-virtual ng-repeat="...">
     <td>1</td>
     <td>2</td>
  </ng-virtual>
</tr>

faire un conteneur redondant : même cet ajout de deux lignes me met mal à l'aise de penser à ce que ce serait si le code devenait plus long.

Un autre problème est que cela va commencer à être fastidieux d'essayer de saisir dans quel niveau de dom le code se trouve actuellement.
Voici un peu de code de @es128

<table>
<thead>...</thead>
    <tr ng-repeat-start="(name, definition) in myList">...</tr>
    <tr>...</tr>
    <tr ng-repeat-end>...</tr>
    <tr>...</tr>
    <tfoot>...</tfoot>
</table>

l'utilisation de nœuds virtuels le transforme en :

<table>
<thead>...</thead>
    <ng-virtual ng-repeat="...">
        <tr">...</tr>
        <tr>...</tr>
        <tr>...</tr>
    </ng-virtual>
    <tr>...</tr>
    <tfoot>...</tfoot>
</table>

La répétition des 3 premiers tr et du dernier tr sont au même niveau, mais si je devais juste parcourir rapidement le code, il y a une chance que je les confonde avec des niveaux différents, ou je commencerai à me trouver calculer de manière fastidieuse (peut-être de manière incorrecte) à quel niveau le code fonctionne, surtout si ces choses commencent à s'imbriquer.

Voici une version particulière de la syntaxe que j'aime (de type B) :

<ul>
  <li>some static prefix item</li>
  <li ng-repeat-block="(name, definition) in myList">{{ something }}</li>
  <li>{{ something else }}</li>
  <li ng-repeat-block-close>{{ something else }}</li>
  <li>some static postfix item</li>
</ul>

@stanvass votre proposition est une variante de ce que @IgorMinar a posté en tant que syntaxe X, le principal problème est que la prise en charge du navigateur n'est tout simplement pas là

Je viens de réaliser qu'avoir à la fois un ng-repeat-start et un ng-repeat-end est redondant dans le cas où vous ne voulez répéter qu'un seul élément interne.

<tr>
  <td ng-repeat-start ng-repeat-end>repeat this</td>
</tr>

Ce serait bien si nous pouvions aussi avoir un ng-repeat-single qui empêcherait cela. ex.

<tr>
  <td ng-repeat-single>repeat this</td>
</tr>

@daegon123 si vous voulez répéter un seul élément, faites-le simplement

<tr>
  <td ng-repeat="...">repeat this</td>
</tr>

Pas besoin de ng-repeat-start ni de ng- repeat-end

@lgalfaso Merci, il semble que je me sois tellement pris dans la syntaxe proposée que j'ai oublié ce que nous avions déjà. J'espère que nous aurons bientôt le ng-repeat-start/end réalisé.

Je pense que cette question ne consiste pas simplement à répéter un élément. Il s'agit plutôt de répéter un ensemble d'éléments sans répéter son parent. c'est- <dt>..<dd>... dire

La syntaxe X est la seule qui soit bien définie une fois que vous commencez à imbriquer les répétitions. Comment écririez-vous ce qui suit dans la syntaxe AD :

<template>
  <dl>
    <ng repeat="book in myList">
      <dt ng-repeat="author in book.authors">{{author.name}}</dt>
      <dd>{{book.title}}</dd>
      <dd>{{book.description}}</dd>
    </ng>
  </dl>
</template>

C'est une meilleure suggestion.
Envoyé depuis My Blackberry®

-----Message d'origine-----
De : daegon123 [email protected]
Date : lun. 06 mai 2013 22:57:16
À : angular/angular.jsangular. [email protected]
Répondre à : "angular/angular.js" [email protected]
Objet : Re : [angular.js] ngRepeat avec DL / DD / DT (#1891)

Je viens de réaliser qu'avoir à la fois un ng-repeat-start et un ng-repeat-end est redondant dans le cas où vous ne voulez répéter qu'un seul élément interne.

<tr>
  <td ng-repeat-start ng-repeat-end>repeat this</td>
</tr>

Ce serait bien si nous pouvions aussi avoir un ng-repeat-single qui empêcherait cela. ex.

<tr>
  <td ng-repeat-single>repeat this</td>
</tr>

Répondez directement à cet e-mail ou consultez-le sur GitHub :
https://github.com/angular/angular.js/issues/1891#issuecomment-17524685

+1, c'est une grosse limitation.

:+1: hâte de voir une solution pour ça ! Je vais utiliser <li> pour le moment, mais j'adorerais refactoriser ce balisage lorsque angular proposera une solution pour cela =)

Le #2783 résoudrait-il cela ?

Oui. Nous avons une solution qui vient d'atterrir : e46100f7097d9a8f174bdb9e15d4c6098395c3f2

Je clos ce sujet.

J'ai l'erreur : <TypeError: Object #<Text> has no method 'hasAttribute'> dans cet exemple simple :

<table>
        <tr ng-repeat-start="value in [1,2,3,4]">I get repeated</tr>
        <tr ng-repeat-end>I also get repeated</tr>
    </table>

Obtenir également le problème en tant qu'États gevgeny.
n'a pas de méthode 'hasAttribute'>

<tr>
                <td data-ng-repeat-start="column in selectedItem.Beds" class="text-center">Avail. Beds</td>
                <td data-ng-repeat-end>Extra Bed Spaces</td>
</tr>

@kharnt0x voir cette demande puul https://github.com/angular/angular.js/pull/2859

Comment le #2783 résoudrait-il cela :

{[{h: "1",
   o: [{h: "1.1",
        o: [{h: "1.1.1"},
            {h: "1.1.2"},
            {h: "1.1.3"}]},
       {h: "1.2",
        o: [{h: "1.2.1"},
            {h: "1.2.2"},
            {h: "1.2.3"}]},

....

Il doit sortir quelque chose comme ceci :

<h1>1</h1>
<h2>1.1</h2>
<h3>1.1.1</h3>
<h3>1.1.2</h3>
<h3>1.1.3</h3>
<h2>1.2</h2>
<h3>1.2.1</h3>
<h3>1.2.2</h3>
<h3>1.2.3</h3> 

Quelle serait la syntaxe ?

@ChrisCinelli Essayez d'utiliser hgroup

<h1>1</h1>
<hgroup>
    <h2>1.1</h2>
        <hgroup>
            <h3>1.1.1</h3>
            <h3>1.1.2</h3>
            <h3>1.1.3</h3>
        <hgroup>
    <h2>1.2</h2>
        <hgroup>
            <h3>1.1.1</h3>
            <h3>1.1.2</h3>
            <h3>1.1.3</h3>
        <hgroup>
<hgroup>

Donc, hgroup semble avoir été supprimé de HTML5 ( http://html5doctor.com/the-hgroup-element/ ), à côté de cela, comme je disais que le problème est plus complexe et que les balises d'en-tête ont été utilisées juste par exemple.
Il s'agit clairement d'un cas d'utilisation qui devrait être autorisé et qui ne rompt en rien avec la philosophie de la vue déclarative d'Angular...

Pour la sortie spécifique que vous recherchez, avez-vous envisagé CSS
Compteurs ?

Voir:
https://developer.mozilla.org/en-US/docs/Web/Guide/CSS/Counters
http://css-tricks.com/almanac/properties/c/counter-increment/

Le mar 18 juin 2013 à 14:46, Chris Cinelli [email protected] a écrit :

Donc hgroup semble avoir été supprimé de HTML5 (
http://html5doctor.com/the-hgroup-element/ ), à côté de ça, comme j'étais
disant que le problème est plus complexe et que les balises d'en-tête ont été utilisées uniquement pour
Exemple.
Il s'agit clairement d'un cas d'utilisation qui devrait être autorisé et qui ne casse pas au
toute la philosophie de la vue déclarative d'Angular...

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/angular/angular.js/issues/1891#issuecomment -19644594
.

J'ai utilisé l'en-tête comme exemple pour que ce soit clair... en réalité, j'ai un <div> relativement complexe avec une structure différente pour chacun des niveaux de la structure de données.

La seule solution que j'ai trouvée jusqu'à présent est de linéariser la structure de données en Javascript et d'utiliser un ng-switch pour différents niveaux et cela me nécessitera un niveau de div supplémentaire.
Cette solution a une surcharge (c'est-à-dire de la mémoire et du processeur pour linéariser la structure des données) et le code HTML sera beaucoup moins clair que le modèle de soulignement que je peux utiliser à la place...

Pouvez-vous faire des directives pour chaque niveau ? Je ne sais pas quel genre de
structure dont vous parlez ici, donc je ne ferais que m'accrocher.
Mais d'après mon expérience, ng-switch n'est presque jamais nécessaire lorsque vous avez
accès aux directives et ng-include, et conduit à des modèles de code spaghetti.

Le mar 18 juin 2013 à 16h27, Chris Cinelli [email protected] a écrit :

J'ai utilisé l'en-tête comme exemple pour que ce soit clair... en réalité j'ai
div relativement complexe avec une structure différente pour chacun des niveaux dans
la structure des données.

La seule solution que j'ai trouvée jusqu'à présent serait de linéariser l'arbre dans
Javascript et utilisez un ng-switch pour différents niveaux.
Cette solution a une surcharge (c'est-à-dire de la mémoire et du processeur pour linéariser les données
structure) et le HTML semblera beaucoup moins clair que le
modèle de soulignement que je peux utiliser à la place...

-
Répondez directement à cet e-mail ou consultez-le sur Gi tHubhttps://github.com/angular/angular.js/issues/1891#issuecomment -19650391
.

Voici à quoi cela ressemble : http://d.pr/i/GSX4
Les étiquettes à peu près courtes (1.xx x), les descriptions, le nombre de coches, etc., proviennent de la base de données.
J'explore la possibilité de convertir cette partie en angulaire mais jusqu'à présent, aucun dé.

La vue actuelle est assez dépourvue de logique et explique relativement clairement ce qui se passe.
Si je comprends bien, vous suggérez à peu près de devoir casser chaque niveau dans un morceau de javascript.

Cela me semble plus désordonné, moins coesif et moins lisible. Étant donné la structure de données qui contient toutes les informations pour afficher ce panneau, pourquoi ai-je besoin d'utiliser du code dans un fichier différent (le module/contrôleur) lorsque la logique est complètement liée à la vue et très spécifique de cette vue ? À mon humble avis, le contrôleur devrait être (et c'est en ce moment dans l'implémentation actuelle):

• récupérer les données du modèle
• passer le modèle à la vue pour que le framework puisse le rendre

Bien sûr, je peux ajouter quelques divs supplémentaires et modifier le CSS, mais si cela est nécessaire pour que cela fonctionne avec Angular, il semble qu'Angular empêche qu'il soit pratique et élégant de faire les choses ici.

Je trouve que la liaison de données dans KnockoutJS, qui permet à la fois les liaisons à un élément html <div data-bind="foreach: ..."> ainsi que la "syntaxe de flux de contrôle sans conteneur", <!-- ko foreach: ... --><!-- /ko --> , sont extrêmement utiles, et je pense que ce serait génial si Angular pourrait prendre en charge un ensemble similaire d'options de syntaxe, tout comme la syntaxe suggérée par @bowsersenior .

Pour plus de détails sur l'option "sans conteneur" de Knockout :
http://knockoutjs.com/documentation/foreach-binding.html

+1 pour la syntaxe virtuelle @mg1075 .
KnockoutJS facilite la gestion des collections dd et imbriquées.
par exemple http://stackoverflow.com/questions/20062032/nested-table-using-ng-repeat