Angular.js: ngRepeat con DL / DD / DT

segundo esto. He tenido este problema por un tiempo.

@IgorMinar hizo un trabajo en un ng-repeat basado en comentarios (https://github.com/angular/angular.js/pull/1646) pero dado que los comentarios no funcionan tan bien en todos los navegadores, no es probable que lo sea fusionado. En su lugar, están buscando una solución alternativa, probablemente con "etiquetas de repetición inicial y final" o "repetición inicial y número de elementos para repetir la etiqueta".

¿Qué tal si permites plantillas dentro de pares como {{}}

quizás:
{{! ng-repeat = "foo in l"

En una nota relacionada, tengo un problema similar con ¿Habría grandes desafíos técnicos para una segunda forma de interpolación?
como {{{}}} que no escapó de los caracteres html pero tampoco creó un
nuevo lapso?

El martes 29 de enero de 2013 a las 12:38 p.m., Pete Bacon Darwin <
[email protected]> escribió:

@IgorMinar https://github.com/IgorMinar hizo un trabajo en un
ng-repeat basado en comentarios (# 1646https: //github.com/angular/angular.js/issues/1646)
pero como los comentarios no se reproducen tan bien en todos los navegadores, no es probable que
fusionarse. En su lugar, están buscando una solución alternativa, probablemente
con "etiquetas de repetición inicial y final" o "repetición inicial y número de
elementos para repetir etiqueta "

-
Responda a este correo electrónico directamente o véalo en Gi

Me encontré con este problema con una tabla que quiere generar dos elementos 'td' por objeto en una matriz.

+1 por agregar esta función. Simplemente me encontré con esta misma limitación.

:Pulgares hacia arriba:

El mismo problema aqui. Me encantaría ver algo como "ng-repeat-children" repitiendo solo los niños pero no el elemento actual o una especie de "ng-omit-tag" (que elimina la etiqueta actual pero deja a los niños en su lugar) para usar junto con ng-repeat. Esto evitaría toneladas de marcado no válido generado para solucionar este problema.

No comprenda completamente la limitación que se está discutiendo. ¿Por qué funciona poner ng-repeat en el elemento padre? http://jsfiddle.net/JyWdT/13/
¿Alguien puede crear un violín que explique el problema con más detalle?

lgalfaso, Your fiddle crea múltiples listas de definiciones, cada una con una definición. El resultado deseado es una lista de definiciones con múltiples definiciones.

O en mi caso, necesito crear un par de elementos "td" para cada elemento de una matriz.
Di que tengo una matriz

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

y necesito generar:

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

No hay forma de lograr eso con angular en este momento.

¿No puedes hacer eso poniendo ng-repeat en el elemento tr?

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

El domingo, 21 de abril de 2013 a las 2:24 p.m., zilles [email protected] escribió:

lgalfaso, Tu violín crea múltiples listas de definición, cada una con una
definición. La salida deseada es una lista de definiciones con múltiples
definiciones.

O en mi caso, necesito crear un par de elementos "td" para cada elemento en
una matriz.
Di que tengo una matriz

[{ nombre: dan , edad: 15 }, { nombre: steve , edad: 21 }]

y necesito generar:

dan15steve21

No hay forma de lograr eso con angular en este momento.

-
Responda a este correo electrónico directamente o véalo en Gi
.

Oh, ya veo, ignora mi comentario anterior
El 21 de abril de 2013 a las 9:09 a.m., "jason turim" jason. [email protected] escribió:

¿No puedes hacer eso poniendo ng-repeat en el elemento tr?

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

El domingo, 21 de abril de 2013 a las 2:24 p.m., zilles [email protected] escribió:

lgalfaso, Tu violín crea múltiples listas de definición, cada una con una
definición. La salida deseada es una lista de definiciones con múltiples
definiciones.

O en mi caso, necesito crear un par de elementos "td" para cada elemento en
una matriz.
Di que tengo una matriz

[{ nombre: dan , edad: 15 }, { nombre: steve , edad: 21 }]

y necesito generar:

dan15steve21

No hay forma de lograr eso con angular en este momento.

-
Responda a este correo electrónico directamente o véalo en Gi
.

Como acabo de encontrar el problema dl / dt + dd, confirmo que un nuevo ng-repeat-children (o ng-repeat-inner) es una directiva obligatoria que falta.

+1

Propuesta de nueva directiva ng-repeat-inner. Si esta propuesta está bien, modificaremos todas las guías.

Creo que sería mejor usar la misma directiva ng-repeat , pero permitir que esa directiva se use en comentarios HTML, como sugiere la publicación original.

Algo como esto debería funcionar:

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

No estoy seguro de cómo se lograría exactamente el principio y el final del bloque que se repetirá ( <!-- /ng-repeat --> fue sugerido por @ProLoser), pero creo que usar comentarios HTML sería una solución elegante.

Dado que los minificadores pueden eliminar los comentarios y otros problemas con los comentarios,
no creo que esto sea genial. Sin embargo, me gusta la idea de usar ng-repeat.
¿Sería factible incluir un atributo ng-repeat-single-root o
algo que cuando se establece en verdadero ejecutará ng-repeat sin la raíz
¿elemento? Por ejemplo:

{I}

{I}

se convertiría:

1

1

2

2

3

3

El martes 23 de abril de 2013 a las 3:54 p.m., Mani Tadayon [email protected] escribió:

Creo que sería mejor usar la misma directiva ng-repeat, pero permitir
para que esa directiva se use en comentarios HTML, como la publicación original
sugiere.

Algo como esto debería funcionar:

{{nombre}}

{{definición}}

No estoy seguro de cómo se repetirá el principio y el final del bloque.
se lograría (inventé elen mi ejemplo),
pero creo que usar comentarios HTML sería una solución elegante.

-
Responda a este correo electrónico directamente o véalo en Gi
.

maxcan, puedo ver las ventajas de "single-root", ya que mantiene el código fuente html válido, pero esa construcción no le permite agregar nada más dentro de la etiqueta "dl" ... Una definición fija, por ejemplo, que desee para incluir antes de su ciclo de definiciones dinámicas. La solución de lgalfaso se encargaría de eso.

@maxcan sin una gran reelaboración o un impacto en el rendimiento, no creo que sea posible agregar esta propiedad ng-repeat-single-root (bueno, agréguela y hágala dinámica en función de ella). Lo racional es que existe una alta probabilidad de que un cambio en esta propiedad provoque una recompilación [ya nadie le gustan las recompilaciones]

Me gusta la sugerencia de @bowsersenior , pero prefiero este como comentario final: <!-- /ng-repeat -->

Es una lástima el éxito en el rendimiento. De todos modos, apoyo firmemente
La solución de @lgalfaso , asumiendo que puede poner la directiva en un div y no
solo un comentario ..

El miércoles 24 de abril de 2013 a la 1:58 p.m., Dean Sofer [email protected] escribió:

Me gusta la sugerencia de @bowsersenior https://github.com/bowsersenior , pero
Preferiría esto como comentario final:

-
Responda a este correo electrónico directamente o véalo en Gi
.

Estoy de acuerdo con @ProLoser en que <!-- /ng-repeat --> es una mejor etiqueta de cierre en el enfoque de comentarios HTML. Una nota, angular permite que las directivas se definan en comentarios HTML, por lo que no creo que los comentarios HTML puedan descartarse como una posible solución para este problema. Tenga en cuenta que los desarrolladores centrales de angular indicaron que planeaban usar comentarios HTML para abordar este problema en esta pregunta de desbordamiento de pila (como lo señala el póster original):

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

No me importa descartarlos siempre que haya una manera de hacerlo sin
comentarios.

El miércoles 24 de abril de 2013 a las 2:41 p.m., Mani Tadayon [email protected] escribió:

Estoy de acuerdo con @ProLoser https://github.com/ProLoser que es una etiqueta de cierre mejor en el enfoque de comentarios HTML. Uno
nota, angular permite que las directivas se definan en comentarios HTML, por lo que no
creo que los comentarios HTML se pueden descartar como una posible solución para esto
problema. Tenga en cuenta que los desarrolladores angulares centrales indicaron que
planeó usar comentarios HTML para abordar este problema en este desbordamiento de pila
pregunta (como se señala en el cartel original):

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

-
Responda a este correo electrónico directamente o véalo en Gi
.

+1 al ng-repeat-inner de @lgalfaso . Finalmente me gustaría algo que lo haga.

Knockout hace esto con comentarios. Estoy intentando portar algo que hice con la etiqueta dl en knockout y parece que no es posible hasta que se resuelva este problema.

Esta es mi opinión, así que sin el aporte de @mhevery o @IgorMinar , tómate esto con un grano de sal.
Veo que hacer que ng-repeat funcione con comentarios es más flexible, de todos modos no parece natural sin un cambio en $ compiler, por lo que puede manejar una directiva de tipo "entre comentarios". La razón es que parece extraño que una directiva deba ocuparse de anidar y mirar fuera del elemento que se le da para hacer lo que se supone que debe hacer.

Si los comentarios / no comentarios son la razón de una controversia en curso, ¿no podemos simplemente tener ambos? Me resulta difícil entender que un problema tan común como este no se haya abordado durante más de 3 meses. Si la razón detrás de esto se debe principalmente a una controversia sobre la implementación, parece más preferible tener algo realmente implementado (y quizás actualizado / agregado en el futuro) que esperar más tiempo sin nada para algo más "óptimo".

Sin embargo, en la mayoría de los casos, me parece que si ng-repeat-inner se refiere a repetir un conjunto de elementos "dentro" de cierto algo, implica que en la mayoría de los casos ya ha creado un contenedor externo exclusivo de algún tipo. Por lo tanto, si bien la implementación de un comentario podría ser más versátil (aunque quizás 1/2 líneas adicionales de código que me gustaría evitar si es posible), creo que puede usarse menos (y quizás debería tener menos prioridad) que una directiva en elemento.

La cuestión de si se deben utilizar comentarios HTML no tiene ninguna relación con el hecho de que esta cuestión ha estado pendiente durante algunos meses. Creo que todo lo que se necesita es un poco de atención por parte de los mantenedores angulares para decidir el problema e implementar una solución.

En caso de que se lo haya perdido, consulte aquí https://github.com/angular/angular.js/pull/1646 sobre problemas con los repetidores basados ​​en comentarios. La solución

Gracias por señalar el n. ° 1646. Hay un comentario en esa discusión de @mhevery que propone "una mejor manera de hacerlo" sin mostrar ningún código (probablemente un error de formato):

¡Ojalá supiéramos cuál era esa "mejor manera"!

El consenso en el equipo central es que actualmente la mejor manera de abordar este problema es una de las siguientes (no nos hemos decidido por la sintaxis, pero la implementación es casi la misma para todos estos):

todos estos ejemplos contienen dos etiquetas td , hice esto a propósito aunque es ilegal porque quería mostrar que el repetidor debería permitir la repetición sobre un número arbitrario de elementos ; sería mejor convertir estos ejemplos para usar la tabla y filas de la tabla, pero estoy a punto de desconectarme ahora y no tengo tiempo para refactorizarlas.

Sintaxis A:

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

Sintaxis B:

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

Sintaxis C:

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

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

A largo plazo, una vez que tengamos un mejor soporte del navegador, comenzaremos a usar el nuevo elemento <template> que nos permitirá hacer simplemente esto:

Sintaxis X:

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

si alguien quiere crear un PR para esta solución, se fusionará. Además, si tiene una preferencia por una sintaxis en particular, dígaselo.

Gracias por el aporte. Desde mi punto de vista, la sintaxis A no es clara para bucles anidados como el siguiente

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

La sintaxis B y C son casi iguales, me gustan ambas alternativas (incluso cuando creo que la sintaxis B es de alguna manera mejor)

A menos que me falte algo, la sintaxis D tiene los mismos problemas de bucles anidados que la sintaxis A

Optaría por B si es posible, simplemente por tener que escribir la menor cantidad de letras. También se ve más simétrico; creo que sería más fácil de manejar debido a la simetría visual.

El comentario de Galfasos señala un dilema interesante. ¿Qué pasa si el bucle anidado en su ejemplo está en el primer elemento en lugar del segundo? Entonces, todas las versiones de la sintaxis ahora no están claras, a menos que me falte algo.

No entiendo muy bien la diferencia entre el ng-repeat-inner propuesto por @lgalfaso y el ng repeat en la sintaxis X, aunque el envoltorio <template> . ¿Alguien podría explicarlo?

Tampoco estoy seguro de haberlo entendido, pero supongo que la etiqueta <ng> no se convierte en parte del DOM, evitando así una estructura de anidación ilegal bajo dl .

En cuanto a las sintaxis propuestas, votaría por B.

Creo que el caso de sintaxis X permite un elemento contenedor ficticio genérico <ng> que no es parte del DOM y puede albergar varias directivas. Esto es más genérico que ng-repeat-inner , que solo se aplica a un caso de uso específico para ng-repeat .

Si la sintaxis X, el objetivo a largo plazo, es solo una versión más genérica de ng-repeat-inner , creo que ng-repeat-inner también debería adoptarse (* no únicamente) junto con una de las propuestas A, B, C, D para lo siguiente:

1. ambas sintaxis X y ng-repeat-inner tienen la misma estructura dom
   : si la sintaxis X es el objetivo a largo plazo, sería bueno tener algo ahora que se alinee en la estructura de manera similar para evitar futuras refactorizaciones.
2. en la mayoría de los casos, ng-repeat-inner sería suficiente de todos modos
   : la intención es crear un contenedor externo para repetir elementos internos.

@ daegon123 la diferencia entre cualquiera de las sintaxis listadas de @IgorMinar (incluyendo X) y ng-repeat-inner es que las sintaxis le permiten repetir arbitrariamente un conjunto de elementos sin un contenedor distinto. Por ejemplo, repita un conjunto de <tr> s mientras haya otros <tr> s no repetidos en table o tbody . En ese caso, los elementos que se van a repetir no tienen un padre distinto al que enlazar 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>

O múltiples definiciones por objeto en 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 Gracias por los comentarios y el código. Esa es exactamente la razón por la que propuse que ng-repeat-inner sea ​​aceptado 'junto' con una de las otras sintaxis enumeradas, pero ver el código real en sus comentarios ha comenzado a hacerme preguntarme si ng-repeat-inner es incluso necesario. Publicaré otro comentario si encuentro algo, ¡gracias de nuevo!

El problema con ng-repeat-inner es que no se puede usar en todos los casos, por ejemplo:

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

debido a que no puede poner un elemento artificial (como div) en ul (por especificación html), ng-repeat-inner no se puede usar aquí.

por cierto con el elemento de plantilla, podremos poner un elemento artificial entre ul y li.

Además, no se apegue demasiado a la sintaxis X, fue solo un ejemplo rápido y sucio de lo que eventualmente seremos capaces de hacer; la sintaxis exacta aún no se ha discutido, pero ya que estoy en eso, aquí hay otro uno:

Sintaxis 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é hay de establecer una identificación para el grupo ng-repeat?
Entonces podríamos adjuntarle elementos libremente desde cualquier nivel. Algo como

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

podría permitir la flexibilidad que necesitamos.

Implementación propuesta de la sintaxis C, resulta que creo que esta es la sintaxis que permitiría que este mismo mecanismo sea fácil para otros elementos y directivas

Buen trabajo Lucas! Pasé la noche tratando de implementar la sintaxis C. Funciona bien, pero el anidamiento no es compatible debido a que la transclusión convierte todos los ng-repeat s en comentarios.

Si no puedo atravesar el DOM buscando ng-repeat-start , no puedo calcular la profundidad del atributo ng-repeat-end para la coincidencia. Su enfoque parece resolver el problema ...

Hmmm ... algo parece estar mal. Faltan documentos en su confirmación, por lo que es posible que no esté usando la sintaxis correcta.

Eche un vistazo a esto:
http://plnkr.co/edit/sVilxKaNrhNM4JrkuQ5r?p=preview

Esperaba que la salida para el caso no anidado fuera:

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

Y para el anidado:

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

Me estoy perdiendo algo?

@lrlopez El ejemplo que pones no usa la última versión del código. Además, hay un </dl> adicional en la línea 23

¡Gracias por su rápida respuesta! Tienes razón, había un </dl> extra en la línea 23. También actualicé la biblioteca. Sin embargo, todavía no puedo ponerme a trabajar con el ejemplo anidado ...

Ok, parece que es un problema real con las directivas de elementos múltiples que están al mismo nivel en el DOM. Se actualizó el PR con una solución para este problema.

Las correcciones como ng-repeat-inner o ng-repeat-next solo resuelven una de las innumerables situaciones en las que los comportamientos vinculantes a los nodos DOM reales lo limitarán.

En lugar de parchear cada directiva individualmente, puede resolver esto para todo el marco agregando soporte para nodos virtuales que no se procesan en el árbol real.

La idea de usar comentarios es similar, pero da como resultado un código antiestético y difícil de leer y aún necesita una forma de nombrar ese nodo y cerrarlo de alguna manera. En lugar de inventar una nueva sintaxis de nodo de comentario, utilice la sintaxis HTML existente.

Piense en ello como un concepto similar a, digamos, las clases silenciosas de 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 a la idea general, pero optaría por algo como ng-repeat-group.

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

Me gusta la idea de los nodos virtuales, pero estoy en contra de que se convierta en una solución general para el problema aquí.

Si es posible, me gustaría limitar la creación de contenedores artificiales. Si bien es posible que el contenedor no aparezca en el html del resultado general, comenzaría a saturar el código html que debe administrarse.

En muchos casos, necesitaremos algún contenedor para contener lo que queremos repetir. ex:

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

(el contenedor aquí es el [tr] s)

usar la solución de nodo virtual propuesta convertiría esto en:

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

hacer un contenedor redundante: incluso esta adición de dos líneas me hace sentir incómodo pensando cómo sería si el código se alargara.

Otro problema es que comenzará a ser tedioso tratar de comprender en qué nivel de dominio se encuentra actualmente el código.
Aquí hay un poco de código 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>

el uso de nodos virtuales convierte esto en:

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

La repetición de los primeros 3 trs y el tr final están en el mismo nivel, pero si solo tuviera que echar un vistazo rápido al código, existe la posibilidad de que los confunda con niveles diferentes, o comenzaré a encontrarme a mí mismo. calculando tediosamente (quizás incorrectamente) en qué nivel está trabajando el código, especialmente si estas cosas comienzan a anidarse.

Aquí hay una versión particular de la sintaxis que me gusta (del tipo 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 su propuesta es una variación de lo que @IgorMinar publicó como sintaxis X, el problema principal es que la compatibilidad con el navegador simplemente no existe.

Me acabo de dar cuenta de que tener un ng-repeat-start y un ng-repeat-end es redundante en el caso de que solo desee repetir un elemento interno.

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

Sería bueno si también pudiéramos tener un ng-repeat-single que evitara esto. ex.

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

@ daegon123 si quieres repetir un solo elemento, hazlo

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

No se necesitan ng-repeat-start ni ng- repeat-end

@lgalfaso Gracias, parece que me he quedado tan atrapado en la sintaxis propuesta que olvidé lo que ya teníamos. Espero que obtengamos pronto el ng-repeat-start / end.

Creo que este problema no se trata simplemente de repetir un elemento. Se trata más de cómo repetir un conjunto de elementos sin repetir su padre. es decir, <dt>..<dd>... - pero había muchos otros buenos ejemplos aquí.

La sintaxis X es la única que está bien definida una vez que comienza a anidar repeticiones. ¿Cómo escribiría lo siguiente en Syntax 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>

Es mejor sugerencia.
Enviado desde My Blackberry®

-----Mensaje original-----
De: daegon123 [email protected]
Fecha: lun, 06 de mayo de 2013 22:57:16
Para: angular / angular.jsangular. [email protected]
Responder a: "angular / angular.js" [email protected]
Asunto: Re: [angular.js] ngRepeat con DL / DD / DT (# 1891)

Me acabo de dar cuenta de que tener un ng-repeat-start y un ng-repeat-end es redundante en el caso de que solo desee repetir un elemento interno.

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

Sería bueno si también pudiéramos tener un ng-repeat-single que evitara esto. ex.

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

Responda a este correo electrónico directamente o véalo en GitHub:
https://github.com/angular/angular.js/issues/1891#issuecomment -17524685

+1, esta es una gran limitación.

: +1: ¡espero ver una solución para esto! Voy a usar <li> por ahora, pero me encantaría refactorizar ese marcado cuando angular salga con una solución para esto =)

¿Resolvería esto # 2783?

Si. Tenemos una solución que acaba de aterrizar: e46100f7097d9a8f174bdb9e15d4c6098395c3f2

Estoy cerrando este tema.

Recibí el error: <TypeError: Object #<Text> has no method 'hasAttribute'> en este simple ejemplo:

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

También obteniendo el problema como afirma gevgeny.
no tiene método '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 vea esta solicitud puul https://github.com/angular/angular.js/pull/2859

¿Cómo resolvería el # 2783 esto?

{[{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"}]},

....

Necesita generar algo como esto:

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

¿Cuál sería la sintaxis?

@ChrisCinelli Intenta usar 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>

Entonces, parece que hgroup se ha eliminado de HTML5 (http://html5doctor.com/the-hgroup-element/), además, como decía, el problema es más complejo y las etiquetas de encabezado se usaron solo por ejemplo.
Este es claramente un caso de uso que debería permitirse y no rompe en absoluto la filosofía de vista declarativa de Angular ...

Para la salida específica que está buscando, ¿ha considerado CSS
Contadores

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

El martes 18 de junio de 2013 a las 2:46 p.m., Chris Cinelli [email protected] escribió:

Entonces parece que hgroup se ha eliminado de HTML5 (
http://html5doctor.com/the-hgroup-element/), además de eso, como estaba
diciendo que el problema es más complejo y que las etiquetas de encabezado se usaron solo para
ejemplo.
Este es claramente un caso de uso que debe permitirse y no se rompe en
toda la filosofía de vista declarativa de Angular ...

-
Responda a este correo electrónico directamente o véalo en Gi
.

Usé el encabezado como ejemplo para dejarlo claro ... en realidad tengo un <div> relativamente complejo con una estructura diferente para cada uno de los niveles en la estructura de datos.

La única solución que encontré hasta ahora es linealizar la estructura de datos en Javascript y usar un ng-switch para diferentes niveles y me requerirá un nivel div adicional.
Esta solución tiene sobrecarga (es decir, memoria y CPU para linealizar la estructura de datos) y el HTML se verá mucho menos claro que la plantilla de subrayado que puedo usar en su lugar ...

¿Puedes hacer directivas para cada nivel? No estoy seguro de que tipo de
estructura de la que estás hablando aquí, así que solo estaría agarrándome de las pajitas.
Pero en mi experiencia, ng-switch casi nunca es necesario cuando tienes
acceso a directivas y ng-include, y conduce a plantillas de código espagueti.

El martes 18 de junio de 2013 a las 4:27 p.m., Chris Cinelli [email protected] escribió:

Usé el encabezado como ejemplo para dejarlo claro ... en realidad tengo
div relativamente complejo con estructura diferente para cada uno de los niveles en
la estructura de datos.

La única solución que encontré hasta ahora sería linealizar el árbol en
Javascript y use un ng-switch para diferentes niveles.
Esta solución tiene sobrecarga (es decir, memoria y CPU para linealizar los datos
estructura) y el HTML se verá mucho menos claro que el
Plantilla de subrayado que puedo usar en su lugar ...

-
Responda a este correo electrónico directamente o véalo en Gi
.

Así es como se ve: http://d.pr/i/GSX4
Las etiquetas bastante cortas (1.xx x), las descripciones, el número de marcas de verificación, etc., provienen de la base de datos.
Estoy explorando la opción de convertir esta parte a Angular pero hasta ahora no hay dados.

La vista actual es bastante menos lógica y deja relativamente claro lo que está sucediendo.
Si lo entiendo bien, está sugiriendo tener que romper todos los niveles en un fragmento de javascript.

Esto me parece más desordenado, menos coherente y menos legible. Dada la estructura de datos que tiene toda la información para mostrar este panel, ¿por qué necesito usar código en un archivo diferente (el módulo / controlador) cuando la lógica está completamente relacionada con la vista y es muy específica de esta vista? En mi humilde opinión, el controlador debería ser (y ahora mismo está en la implementación actual):

• obtener los datos del modelo
• pasar el modelo a la vista para que el marco pueda representarlo

Claro que puedo agregar algunos divs adicionales y cambiar el CSS, pero si esto es necesario para que funcione con Angular, parece que Angular está en el camino de cómo es conveniente y elegante hacer las cosas aquí.

Encuentro que el enlace de datos en KnockoutJS, que permite ambos enlaces a un elemento html <div data-bind="foreach: ..."> así como la "sintaxis de flujo de control sin contenedor", <!-- ko foreach: ... --><!-- /ko --> , es extraordinariamente útil, y creo que sería genial si Angular podría admitir un conjunto similar de opciones de sintaxis, muy similar a la sintaxis que sugirió @bowsersenior .

Para obtener más detalles sobre la opción "sin contenedor" de Knockout:
http://knockoutjs.com/documentation/foreach-binding.html

+1 para la sintaxis virtual @ mg1075 .
KnockoutJS facilita el manejo de dd y colecciones anidadas.
por ejemplo, http://stackoverflow.com/questions/20062032/nested-table-using-ng-repeat