Reprise du message précédent :

 
J'ai pas le temps de vérifier, mais ça ressemble à un bug du input helper

J'ai un modèle qui contient des foo. Un foo a plusieurs bars.
J'ai également un BarController que j'aimerais utiliser pour décorer un bar avec une CP (que l'on nommera label).
 
Comment dans mon each de foo je peux spécifier un controller à bar (et non pas bars) sans y imbriquer un autre each ?
 

{{#each foo in model.foos itemController='foo'}}
    <span>{{foo.bars.firstObject.label}}</span>
{{/each}}

 
Sans controller mentionné, la CP n'est pas évaluée (et donc pas de valeur), avec itemController='bar' dans le span :

Un peu lié à ma question précédente : comment j'accède à une propriété d'un controller à partir d'un autre ?
 
foo contient plusieurs bars, ils ont chacun un controller d'item. Le controller de bar défini une CP isOk, et je cherche à définir une CP dans le controller foo comme true si tous les bar.isOk le sont :
 

// Dans FooController
isOk: function() {
  return this.get('model.bars').every(function(bar) {
    // return bar.isOk; ?
  });
}.property('model.bars.@each.<propriété sur laquelle est bindée le isOk de bar>')

Réponses

{{#each foo in model.foos itemController='foo'}}
    {{#with foo.bars.firstObject as firstBar controller='bar'}}
        <span>{{firstBar.label}}</span>
    {{/with}}
{{/each}}

// Dans FooController
needs: 'bar',
isOk: function() {
  return this.get('model.bars').every(function(bar) {
    var barController = this.get('controllers.bar');
    return barController.get('isOk');
    // Pour ce cas spécifique, je ne sais pas comment appliquer le contexte de l'élément 'bar' particulier à la requête vers son controller
  });
}.property('model.bars')

Du coup je peux rajouter une question dans le pipe    
 
J'utilise un component auquel je viens binder une action.
 

{{#each tree in forest itemController='tree'}}

    {{#with tree.bananas.firstObject as firstBanana controller='banana'}}
        {{mycomponent banana=firstBanana action='eatBanana'}}
    {{/with}}

    {{#each banana in tree.bananas itemController='banana'}}
        {{mycomponent banana=banana action='eatBanana'}}
    {{/each}}

{{/each}}

 
Dans le premier cas (utilisation de with avec controller), l'action n'est pas bublée au BananaController, il me faut définir eatBanana dans les actions de TreeController.
 
Dans le second cas (utilisation de each avec itemController), l'action est bien bublée vers le BananaController.
 
Quelqu'un pour m'expliquer cette différence de comportement ?

Je pense que toutes mes questions sont liées à une notion de contexte que je ne pige pas complètement, parce qu'itemController (dans le each) semble le changer là où 'controller' (dans le with) non.

Même chose pour une vue, j'ai BananaView qui ne tape pas automatiquement sur BananaController en fonction du contexte, du coup je me demande comment je peux associer un controller à une vue donnée.

Je ne décourage pas, ce topic est peut-être encore vivant
 
A partir d'un composant, je veux transmettre une action aux composants enfants du DOM, et non pas parent.
 
Le use case est un resize. J'ai un composant faisant office de container, l'une de ses actions génère un resize de son DOM. J'aimerais qu'il propage cet événement vers le bas pour adapter la présentation de mon contenu (et non pas sa nature) à l'espace disponible.
 
Exemple : le component container permet à deux tables alignées horizontalement de collapser tour à tour. Par défaut, elles occupent toutes deux une certaine largeur. Sous action de l'utilisateur, l'une peut être masquée, l'autre prend dans ce cas toute la largeur disponible. Cette table comprend des éléments enfants, dont je veux adapter la présentation en fonction de l'espace.
 
Si la table est de largeur "normale" (les deux tables sont affichées), son contenu est un texte ("42 éléments" ). Si la table est étendue, le contenu de cette cellule n'est plus "42 éléments", mais "élément 1, élément 2, ...".
 
Le composant qui gère l'affichage du contenu en fonctionne bien en statique mais ne réagi pas aux changements de largeur. A part une action, je vois pas comment faire ça proprement mais action up, data down.

Pff, j'ai du retard par ici avec mes vacances

Toutes les questions attendent une réponse ?

// Dans FooController
needs: 'bar',
isOk: function() {
  return this.get('model.bars').every(function(bar) {
    var barController = this.get('controllers.bar');
    return barController.get('isOk');
    // Pour ce cas spécifique, je ne sais pas comment appliquer le contexte de l'élément 'bar' particulier à la requête vers son controller
  });
}.property('model.bars')

Ca va dépendre de comment tu t'en sers. Un moyen de faire c'est de charger les `bars` dans un `BarsController` qui lui aura `BarController` comme itemController.

// Dans FooController
needs: 'bars',
isOk: function() {
  return this.get('controllers.bars').every(function(barController) {
    return barController.get('isOk');
    // Pour ce cas spécifique, je ne sais pas comment appliquer le contexte de l'élément 'bar' particulier à la requête vers son controller
  });
}.property('controllers.bars')
 
BarsController = Ember.ArrayController.extend({
  itemController: 'bar'
})
 
BarController = Ember.ObjectController.extend({
  isOk: function() {
    ....
  }.property()
})

Ca marche en Ember 1.x mais ca ne sera pas compatible Ember 2.0 si je ne m'abuse.

{{#each tree in forest itemController='tree'}}
 
    {{#with tree.bananas.firstObject as firstBanana controller='banana'}}
        {{mycomponent banana=firstBanana action='eatBanana'}}
    {{/with}}
 
    {{#each banana in tree.bananas itemController='banana'}}
        {{mycomponent banana=banana action='eatBanana'}}
    {{/each}}
 
{{/each}}

`with` te crée un alias sans changer le contexte, `each` te change le contexte

Les actions remontent le DOM. Si tu veux passer quelque chose à composant fils ( dans ton cas j'imagine que le parent agit/controlle sur la largeur des tables, donc binder `width` ).

 
OK, je comprend le principe. C'est quoi la méthode pour Ember 2 du coup ?
 

 
Comment je change le contexte pour un élément unique (sans passer par each) ? Un if ? Ou a définir dans la vue ?
 
Ça m'intéresse également d'avoir ton point de vue sur le sujet suivant :
 

 
Tout ça est très lié à la notion de contexte que je ne comprend pas des masses j'ai l'impression. Je vais lire The View Layer, mais si tu as quelques pointeurs rapides je prends.
J'imagine que  

me donne une bonne indication, je vais tester controller: 'controller-name' dans une view.
 

 
J'ai un peu de mal à saisir. J'imagine que tu parles de binder la propriété CSS du parent dans le composant enfant, mais j'ai aucune idée de la manière de procéder.
 
Merci encore pour tes lumières.

 
Je tâtonne toujours, mais je pense avoir saisis comment fixer le contexte.
 
Soit Foo (model), FooView, FooController et foo-template.
 
Le model défini une propriété name ("Yay" ).
Le controller défini une propriété longName ("Yayyyyyy" ).
 
Dans un template parent :

{{render 'foo' fooModel}}

 
Dans foo-template

{{model.name}}
{{longName}}
{{fooModel.model.name}}
{{fooModel.longName}}

 
Output :

<!---->
<!---->
Yay
Yayyyyyy

 
La doc indique pourtant que les propriété doivent être accédées directement.
 
Plus fort, si au lieu de Ember.Controller.extend j'utilise Ember.ObjectController.extend, j'ai le comportement attendu (propriétés accessibles sans le préfixe du modèle) mais avec le warning de deprecation d'ObjectController.
 
D'où mes questions : pourquoi et est-ce que je suis sur la bonne piste ?

 
Je ne sais pas, j'ai pas encore potassé comment ça doit marcher. Mais je vais en avoir besoin pour mon projet, donc je compte avoir une réponse un de ces 4.
 

 
Tu peux utiliser `render` ( pas besoin de `controller-name` )
 
Ca devrait répondre à ta question:
 
http://emberjs.jsbin.com/jogeqi/2/edit
 
Les 2 techniques donnent le même résultat.
 
Le changement de contexte est un concept compliqué qui va disparaitre avec Ember 2.0. Essaie d'éviter ça si tu peux.
 
 

 
Ma phrase avait pas l'air d'être finie surtout    
 
Je ne suis pas sur de bien comprendre ton exemple. J'imaginais que le composant parent avait une propriété reflétant sa largeur par exemple. Ce que je tentais d'expliquer, c'est de passer cette propriété au composant fils qui peut décider de l'utiliser pour calculer sa propre largeur.

{{render 'foo' fooModel}}

{{model.name}}
{{longName}}
{{fooModel.model.name}}
{{fooModel.longName}}

<!---->
<!---->
Yay
Yayyyyyy

 
Je suis un peu surpris de certains résultats, mais voilà comment ca doit marcher :
 
Quand tu utilises `render`, Ember va assigner la variable que tu passes ( `fooModel` ) à la propriété `model` du controlleur associé à la vue ( convention ). Ce controlleur va être le contexte de la vue, c'est à dire que `this` dans ton template sera le controlleur.
 
Donc {{longName}} dans ton template tente d'accéder à `longName` sur ton controlleur. Pareil si tu utilises {{name}}.
Dans tes 2 cas, le controlleur expose `longName` donc tu vois quelque chose dans ta vue.
 
Avec un `Ember.Controller`, rien n'est affiché car le controlleur n'a pas de propriété `name`. Il faudrait écrire {{model.name}}
Avec un `Ember.ObjectController`, le controlleur devient un proxy du model: si le controlleur n'expose pas une propriété, il va déléguer au model sous jacent. C'est pour ça que {{name}} fonctionne dans ce cas ( {{model.name}} continue de fonctionner ).
 
Apparemment le concept de proxy est compliqué à manipuler et à expliquer pour la communauté, c'est pour ça que seul `Ember.Controller` va subsister dans Ember 2.0.

Privilégier render plutôt que with, c'est bien ça ?
 

 
Le parent ne défini pas de propriété liée à la largeur. Le parent est un composant qui sous action de l'utilisateur change de classes, classes qui jouent sur sa largeur visible. Ce que je souhaite c'est qu'à l'action de l'utilisateur sur ce composant parent, récupérer cet événement pour modifier le composant enfant.
 

 
Tes explications confirment ce que j'avais lus, mais j'obtiens des résultats opposés. Je pense que le problème viens du contexte dans lequel j'utilise render, ici dans une each.
 
Ça explique ce que je cherche à faire : http://emberjs.jsbin.com/xujakozaw [...] ,js,output
Et il fonctionne.
 
J'ai finalement trouvé pourquoi mes résultats précédents n'étaient pas cohérent avec le comportement dont on parle : un itemController identique était déjà déclaré.
 

{{#each foo in model.foos itemController='foo'}}
    <!-- Plein de code qui était utilisé avant que je ne déclare le render -->
    {{render 'foo' foo}}
{{/each}}

En complément des questions précédentes, j'aurais utilité d'une petite recette "générale".
 
La doc est détaillée, mais également très théorique. Ici, j'ai l'impression d'être dans le cas où j'ai besoin de savoir comment refaire le papier-peint dans ma chambre, et où je ne trouve que des ressources sur les réactions chimiques induites par la colle utilisée par Ember en fonction des typologies de murs. Ajoute à ça le fait que je souhaite rester le plus possible bleeding-edge et qu'Ember 2 déprécie un maximum de mécanismes, et tu comprendras que je m'y perd.
 
Hier par exemple, j’apprends que l'helper 'render' va être déprécié au profit des components. De ma maigre compréhension de l'ensemble, je vois mal comment les components peuvent couvrir le périmètre de render puisque je m'en sers pour switcher le contexte.
 
Je me base sur la table récapitulative des helpers ainsi que sur ce que je sais des components.
 
Aujourd'hui j'applique la recette suivante pour séparer mon code :
- si j'ai besoin d'un template et d'une vue spécifique, je créé un component ;
- si j'ai besoin d'un template scopé sur un controller (et donc un model) et d'éventuellement une vue spécifique, j'utilise render qui est en phase de dépréciation.
 
En résumé :
 

{{#each bars itemController='bar' as |bar|}}
    // Ici, comment je peux changer le contexte ?
    {{#with bar.foo as |foo| }}
         // le contexte shifting est apparemment (?) déprécié, mais je veux utiliser ici foo-template, FooController...
    {{/with}}
{{/each }}

et

 
Quel est le moyen privilégier pour afficher un ensemble template + view + controller + model indépendamment d'un contexte donné ?

{{#each bars itemController='bar' as |bar|}}
    // Ici, comment je peux changer le contexte ?
    {{#with bar.foo as |foo| }}
         // le contexte shifting est apparemment (?) déprécié, mais je veux utiliser ici foo-template, FooController...
    {{/with}}
{{/each }}

 
Le minimum que tu puisses faire si tu réutilises pas `BarController` ou `FooController` à différents endroits :
 

{{#each bars itemController='bar' as |bar|}}
    {{my-foo foo=bar.foo}}
{{/each }}

 
Comme je l'ai expliqué, je n'ai pas encore étudié la problématique du contrôleur servant de contexte pour différentes vues ( je vais me bouger cette semaine, vu que ce n'est pas la 1ère fois qu'on me pose la question ).
 

 
Un composant répond à ces critères

Je limitais le component à des paramètres "simples" (mappe un string plutôt qu'un objet de mon modèle par exemple).
 
Si tu me dis que ce n'est pas forcément une best practice, tant mieux. Je m'imposais aussi cette limitation parce que je n'avais pas trouver de moyen de mapper un component à un controller, mais effectivement un changement de contexte avant ça déclaration peut faire l'affaire (si je comprend bien).
reste donc à creuser les changements de contexte.
 
Merci

On cherche un presta Ember expérimenté en région parisienne. MP vous avez des pistes.

 
Tu n'as pas besoin d'un changement de contexte avant.
 
Tu passes la valeur/objet qui t'intéresse au composant. Et le contexte du template de ton composant est le composant lui même = changement de contexte comparé à la vue qui a inséré ce composant.

 
Moi je veux bien voir une description de job et une fourchette de salaire pour savoir à quoi ça ressemble le marché en France.

Ember 2.0 vient d'être publié http://emberjs.com/blog/2015/08/13 [...] eased.html

Sacré chemin parcouru depuis environ 4 ans    
 
Bon, je sais pas pour quand cela sera pour nous au boulot, on progresse doucement dans nos mises à jour, mais on est sacrément derrière pour l'instant ( 1.8 pour Ember, beta 6 pour Ember Data )

Je suis en 1.13, mais j'ai quelques deprecation warnings que j'ai pas eu le temps d'enlever. Du coup, je devrais migrer dans quelques semaines.

Tu avais commencé avec quelle version ?
 
Chez nous c'est pré 1.0, du coup c'est pas au top niveau "best practices", mais on a fait de très gros progrès dernièrement.

1.4.
En règle général, je saute une version sur deux.

J'ai un pb super simple, je pense que j'ai raté le truc dans la doc.
J'ai dans mon modèle un tableau d'éléments, et dans ma vue, je veux un tableau de vues (non-DOM, cherchez pas y'a pas de templates) qui reflète exactement le tableau d'éléments.
actuellement je fais tout à la main, mais je suis sur que ça doit exister dans le système:
 

 
le top pour moi ça serait une version non DOM de EMBER.COLLECTIONVIEW je crois.

Pas sûr de comprendre ce que représente une vue non DOM.
 
Je ne comprends pas ce que le code est censé faire / produire.

en l'occurence c'est une vue où les éléments sont des noeuds dans un graphe de scène de Three.js
 
le code produit (et maintient la relation) un élément de vue par élément de modèle.

quelqu'un sait scroller directement à l'élément actif d'une liste quand on rentre dans une route (et pas à chaque click) ?  
 
dans cet exemple ils jouent la feinte en touchant pas du tout aux vues:  
http://guides.emberjs.com/v1.10.0/ [...] e_changes/

 
Je comprends toujours pas, mais je suis fatigué
 
Tu peux me mettre un lien vers le code ?

 
C'est la route qui définit l'élément actif ?

https://github.com/nraynaud/webgcod [...] ew.js#L216
 

ouais, pour une fois je suis vraiment dans le cas simple, comme dans le tuto où la liste est affichée par un {{#each}}, simplement elle est longue (et y'a du bordel au-dessus) quand on rentre dans la page elle peut être hors de la fenêtre.

c'est sensé fonctionner un enchaînement de de computed comme ça ?  
 
J'observe "canSendProgram" et je l'ai lu une première fois dans init mais je reçois pas d'évènement d'observation.
Et computingEnabledOperations est toujours vide.

 
 
1) Au 1er abord, je dirais que tu dois utiliser le hook `didInsertElement` dans la vue de ta route. Ca veut dire que les éléments sont affichés et que tu peux enfin scroller jusqu'à l'élément sélectionné
 
2) Tu as des hook sur chaque route ( `activate` et `deactivate` ) ( http://emberjs.com/api/classes/Emb [...] t_activate )
 
3) ca vient d'une librairie externe / qui a besoin de ça pour quoi ?
 
4) les observers, c'est un peu le mal. La plupart du temps, ca peut être remplacé par une computed property ou une action. Sinon, il faudrait que je débugge le truc, ma meilleure idée sans rien connaitre c'est un probleme de dependent key.
 
5) cf rep 4. Il observe quoi ?
 
6) J'ai pas beaucoup utilisé Firebase. Je sais qu'ils avaient du retard par rapport à Ember Data à une époque ( un comble ). Tu utilises quelles versions et quel type d'associations ( belongsTo/hasMany, sync/async, embedded, etc.. ) ?

2) deactivate était pas appelé (je sais pas pourquoi)
 
3) j'envoie et reçois du postmessage et je reçois des fichiers utilisateur par drag/drop
 
4) les computed properties reposent sur les observateurs, j'utilise un mot pour l'autre, en général j'essaye de tout faire en computed, puis quand ça bugge trop ou quand il faut sortir de ember, j'utilise des observateurs directs (il faut bien voir que manipuler du DOM dans des templates est une infime partie de mon code, le gros du truc c'est gérer les workers et webgl).
 
5) il observait plusieurs trucs et il firerait une fois par dépendant, même s'ils avaient une cause commune. Et aussi quand ember-fire sauve, il lance tous les observateurs de tous les modèles chargés (donc dans mon cas ça relance tous les calculs lourds).
 
6) j'ai  
job->hasmany(operations, embedded)
job->hasmany(shapes, embedded)
job->belongsTo(jobSummary, async)
 
operation->belongsTo(job)
operation->belongsTo(shape)
 
shape->belongsTo(manualShape, embedded)
operation->belongsTo(job)
 
manualShape-> j'ai voulu faire un belongsTo(shape) pour un élément particulier qui en référence un autre, mais ça pète tout le template sans rien dire, même quand je mets le reverse à null.
 
le "jobSummary" c'est une entité spéciale, stockée dans une autre branche de l'arbre, il permet de faire l'index de tous les jobs, sans charger l'intégralité des jobs et leur dépendances en mémoire. Elles sont embedded, ça veut dire qu'on tirait tous les .stl de l'utilisateur quand il allait sur l'index. Le lien entre jobsummary et job est async, donc on tire le job du serveur qu'en navigant dessus.

 
 
2) si tu restes dans la meme route mais que seul le modele change, deactivate ne sera pas appelé.
 
3) je pose la question pour savoir quel est le meilleur endroit pour ajouter/enlever les event handlers dont tu as besoin. Si c'est global à l'application, j'aurai tendance à gérer ça dans un initializer. Si c'est dans une vue/route spécifique, la route me semble un meilleur choix
 
je réponds à la suite une fois que je suis dans mon train

2) ouais, j'ai lu ça, mais dans le debugger la route en gras avant changé, sans que le truc soit appelé.
 
3) c'est compliqué. en gros dans un sens l'appli broadcast si elle est capable d'expédier un programme tout de suite maintenant (la route courante est un job, le job a au moins une opération active, et toutes les opérations activées ont fini leur calcul), à la réception, y'a à boire et à manger (la position courante de l'outil, envoie-moi le programme courant etc.)

4) une CP est calculée quand elle est consommée. Ca veut généralement dire qu'elle doit faire partir d'une chaine de dépendance de propriétés dont une extrémité est utilisée dans un template. La chaine pouvant se réduire à un élément. C'est pas la seule solution, mais la plus courante.
 
5) Pas facile de répondre dans l'absolu sans exemple concret. Un observer est synchrone et est executé à chaque fois, au moment du changement. Une CP n'est executée que lorsqu'elle est consommée. en mettant un point d'arret dans la fonction et en regardant la call stack, il est possible de savoir qui l'utilise. Mais ca ne répond pas à la question pourquoi elle est reéxecutée. Pour ça il faut regarder qui invalide son cache.
 
6) le support d'embedded records n'est pas ce que je maitrise le plus, et je ne suis pas sur que c'est ce qui marche le moins mal dans Ember Data. Tu utilises quelles version d'Ember, Ember Data et EmberFire?

 
2) une autre option est que c'est une route parente qui n'a pas changée.
 
Ex:
 
/articles/1/comment/2 -> /articles/1/comment/3
 
deactivate ne sera jamais appelée
 
/articles/1/comment/2 -> /articles/1/associated/4
 
deactivate va être appelée seulement pour CommentRoute

4) ouais, j'essaye de toujours les lire dans un "init" mais clairement c'est le merdier de savoir combien de fois ça va se déclencher et si ça va se déclencher, du coup j'utilise du on('init') dans tous les sens et du Ember.run.debounce(). C'est le fail du framework d'observation.
 
6)
Ember Inspector
1.9.3
Ember
1.7.0
Ember Data
1.0.0-beta.11
EmberFire
0.0.0
Handlebars
1.3.0
jQuery
1.11.1
 
EmberFire 0.0.0 ( on est pas sortis de l'auberge )
 
Les embedded record j'ai déjà expliqué pourquoi: je veux pouvoir gérer les droits d'accès à un projet (un job) simplement en gérant les droits du noeud racine. Et pareil les jobs sont embedded dans les users.