Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2774 connectés 

 


 Mot :   Pseudo :  
 
 Page :   1  2  3  4  5  6  7  8  9  10  11
Auteur Sujet :

Ember.js - Framework JS - Ember Octane disponible !

n°2256387
youmoussa
Ecrou-vis
Posté le 22-04-2015 à 18:20:40  profilanswer
 

Reprise du message précédent :

LeRiton a écrit :

Avec l'input helper, les noms d’événements doivent être dasherisés :

Code :
  1. {{input action='foo' on='focus-out'}}


En utilisant le helper action, seul le camelCase fonctionne :

Code :
  1. {{action 'bar' on='doubleClick'}}


 
WTF?


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

mood
Publicité
Posté le 22-04-2015 à 18:20:40  profilanswer
 

n°2256679
LeRiton
Posté le 27-04-2015 à 13:14:25  profilanswer
 

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 ?
 

Code :
  1. {{#each foo in model.foos itemController='foo'}}
  2.    <span>{{foo.bars.firstObject.label}}</span>
  3. {{/each}}


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

Citation :

Assertion Failed: A helper named 'foo.bars.firstObject.label' could not be found

n°2256700
LeRiton
Posté le 27-04-2015 à 15:28:50  profilanswer
 

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 :
 

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

n°2257548
LeRiton
Posté le 07-05-2015 à 10:33:22  profilanswer
 

Réponses :o

LeRiton a écrit :

Comment dans mon each de foo je peux spécifier un controller à bar (et non pas bars) sans y imbriquer un autre each ?


 

Code :
  1. {{#each foo in model.foos itemController='foo'}}
  2.    {{#with foo.bars.firstObject as firstBar controller='bar'}}
  3.        <span>{{firstBar.label}}</span>
  4.    {{/with}}
  5. {{/each}}


 

LeRiton a écrit :

Un peu lié à ma question précédente : comment j'accède à une propriété d'un controller à partir d'un autre ?


 

Code :
  1. // Dans FooController
  2. needs: 'bar',
  3. isOk: function() {
  4.  return this.get('model.bars').every(function(bar) {
  5.    var barController = this.get('controllers.bar');
  6.    return barController.get('isOk');
  7.    // 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
  8.  });
  9. }.property('model.bars')


 

n°2257551
LeRiton
Posté le 07-05-2015 à 10:48:55  profilanswer
 

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

Code :
  1. {{#each tree in forest itemController='tree'}}
  2.    {{#with tree.bananas.firstObject as firstBanana controller='banana'}}
  3.        {{mycomponent banana=firstBanana action='eatBanana'}}
  4.    {{/with}}
  5.    {{#each banana in tree.bananas itemController='banana'}}
  6.        {{mycomponent banana=banana action='eatBanana'}}
  7.    {{/each}}
  8. {{/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 ?

n°2257626
LeRiton
Posté le 07-05-2015 à 16:18:39  profilanswer
 

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.

Message cité 2 fois
Message édité par LeRiton le 07-05-2015 à 16:19:23
n°2258296
LeRiton
Posté le 18-05-2015 à 15:00:26  profilanswer
 

Je ne décourage pas, ce topic est peut-être encore vivant :o
 
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.

n°2258329
youmoussa
Ecrou-vis
Posté le 19-05-2015 à 03:28:06  profilanswer
 

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

 

Toutes les questions attendent une réponse ?


Message édité par youmoussa le 19-05-2015 à 03:29:42
n°2258331
youmoussa
Ecrou-vis
Posté le 19-05-2015 à 03:46:56  profilanswer
 

LeRiton a écrit :

 
Code :
  1. // Dans FooController
  2. needs: 'bar',
  3. isOk: function() {
  4.  return this.get('model.bars').every(function(bar) {
  5.    var barController = this.get('controllers.bar');
  6.    return barController.get('isOk');
  7.    // 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
  8.  });
  9. }.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.

 
Code :
  1. // Dans FooController
  2. needs: 'bars',
  3. isOk: function() {
  4.  return this.get('controllers.bars').every(function(barController) {
  5.    return barController.get('isOk');
  6.    // 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
  7.  });
  8. }.property('controllers.bars')
  9.  
  10. BarsController = Ember.ArrayController.extend({
  11.  itemController: 'bar'
  12. })
  13.  
  14. BarController = Ember.ObjectController.extend({
  15.  isOk: function() {
  16.    ....
  17.  }.property()
  18. })
 

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

Message cité 1 fois
Message édité par youmoussa le 19-05-2015 à 03:47:09
n°2258332
youmoussa
Ecrou-vis
Posté le 19-05-2015 à 03:48:30  profilanswer
 

LeRiton a écrit :

Du coup je peux rajouter une question dans le pipe  [:jar jar]

 

J'utilise un component auquel je viens binder une action.

 
Code :
  1. {{#each tree in forest itemController='tree'}}
  2.  
  3.    {{#with tree.bananas.firstObject as firstBanana controller='banana'}}
  4.        {{mycomponent banana=firstBanana action='eatBanana'}}
  5.    {{/with}}
  6.  
  7.    {{#each banana in tree.bananas itemController='banana'}}
  8.        {{mycomponent banana=banana action='eatBanana'}}
  9.    {{/each}}
  10.  
  11. {{/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 ?

 

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

 


LeRiton a écrit :

Je ne décourage pas, ce topic est peut-être encore vivant :o

 

A partir d'un composant, je veux transmettre une action aux composants enfants du DOM, et non pas parent.

 
LeRiton a écrit :

Je ne décourage pas, ce topic est peut-être encore vivant :o
Les actions remontent le DOM. Si tu veux passer quelque chose à composant fils ( dans ton cas tu peux binder la taille du composant 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.

 

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` ).

Message cité 1 fois
Message édité par youmoussa le 19-05-2015 à 03:53:32
mood
Publicité
Posté le 19-05-2015 à 03:48:30  profilanswer
 

n°2258454
LeRiton
Posté le 20-05-2015 à 14:35:04  profilanswer
 

youmoussa a écrit :

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.
[...]
Ca marche en Ember 1.x mais ca ne sera pas compatible Ember 2.0 si je ne m'abuse.


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

youmoussa a écrit :

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


 
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 :
 

LeRiton a écrit :

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.


 
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  

Citation :

Ember sets the controller variable on the Handlebars context whenever a rendered view has a controller property. If a view has no controller property, it inherits the controller variable from the most recent view with one.


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

youmoussa a écrit :

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` ).


 
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.

n°2258460
LeRiton
Posté le 20-05-2015 à 16:07:00  profilanswer
 

LeRiton a écrit :

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


 
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 :

Code :
  1. {{render 'foo' fooModel}}


 
Dans foo-template

Code :
  1. {{model.name}}
  2. {{longName}}
  3. {{fooModel.model.name}}
  4. {{fooModel.longName}}


 
Output :

Code :
  1. <!---->
  2. <!---->
  3. Yay
  4. 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 ?

n°2258464
youmoussa
Ecrou-vis
Posté le 20-05-2015 à 16:46:54  profilanswer
 

LeRiton a écrit :


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


 
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.
 

LeRiton a écrit :


Comment je change le contexte pour un élément unique (sans passer par each) ? Un if ? Ou a définir dans la vue ?


 
 

LeRiton a écrit :


Ça m'intéresse également d'avoir ton point de vue sur le sujet suivant :
 
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.


 
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.
 
 

LeRiton a écrit :


 
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.


 
Ma phrase avait pas l'air d'être finie surtout  :D  
 
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.

n°2258467
youmoussa
Ecrou-vis
Posté le 20-05-2015 à 17:03:09  profilanswer
 

LeRiton a écrit :


 
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 :

Code :
  1. {{render 'foo' fooModel}}


 
Dans foo-template

Code :
  1. {{model.name}}
  2. {{longName}}
  3. {{fooModel.model.name}}
  4. {{fooModel.longName}}


 
Output :

Code :
  1. <!---->
  2. <!---->
  3. Yay
  4. 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 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.

n°2258526
LeRiton
Posté le 21-05-2015 à 13:25:22  profilanswer
 

youmoussa a écrit :

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.


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

youmoussa a écrit :

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.


 
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.
 

youmoussa a écrit :


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


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

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


 
 
 

n°2258741
LeRiton
Posté le 26-05-2015 à 11:17:30  profilanswer
 

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

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


 

Citation :

While top-level controllers will not be removed in 2.0 (see more below), we will remove all of the other uses of controllers from templates (such as #with controller=, {{render}}, itemController and others).


et

Citation :

The context-shifting forms of #each and #with have been deprecated in favor of the named-parameter forms.


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

n°2258760
youmoussa
Ecrou-vis
Posté le 26-05-2015 à 16:57:14  profilanswer
 

LeRiton a écrit :

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

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


 

Citation :

While top-level controllers will not be removed in 2.0 (see more below), we will remove all of the other uses of controllers from templates (such as #with controller=, {{render}}, itemController and others).


et

Citation :

The context-shifting forms of #each and #with have been deprecated in favor of the named-parameter forms.




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

Code :
  1. {{#each bars itemController='bar' as |bar|}}
  2.    {{my-foo foo=bar.foo}}
  3. {{/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 ).
 

LeRiton a écrit :


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


 
Un composant répond à ces critères [:cosmoschtroumpf]

n°2259028
LeRiton
Posté le 29-05-2015 à 09:48:43  profilanswer
 

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

n°2260167
LeRiton
Posté le 11-06-2015 à 15:38:24  profilanswer
 

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

n°2260169
youmoussa
Ecrou-vis
Posté le 11-06-2015 à 15:46:31  profilanswer
 

LeRiton a écrit :

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


 
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.

n°2260170
youmoussa
Ecrou-vis
Posté le 11-06-2015 à 15:47:10  profilanswer
 

LeRiton a écrit :

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


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

n°2264355
tryptique
Stay hungry, stay foolish
Posté le 13-08-2015 à 13:36:05  profilanswer
 

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


---------------
"J'ai les goûts les plus simples du monde, je me contente du meilleur" O. Wilde - Freedom of time is the new luxury. Time to sleep, work, play, relax, travel, inspire and get inspired. Time to write your story.
n°2264364
youmoussa
Ecrou-vis
Posté le 13-08-2015 à 16:27:19  profilanswer
 

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 :/ )

n°2264373
tryptique
Stay hungry, stay foolish
Posté le 13-08-2015 à 20:15:45  profilanswer
 

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.


---------------
"J'ai les goûts les plus simples du monde, je me contente du meilleur" O. Wilde - Freedom of time is the new luxury. Time to sleep, work, play, relax, travel, inspire and get inspired. Time to write your story.
n°2264375
youmoussa
Ecrou-vis
Posté le 13-08-2015 à 20:36:07  profilanswer
 

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.

n°2264376
tryptique
Stay hungry, stay foolish
Posté le 13-08-2015 à 20:50:32  profilanswer
 

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


---------------
"J'ai les goûts les plus simples du monde, je me contente du meilleur" O. Wilde - Freedom of time is the new luxury. Time to sleep, work, play, relax, travel, inspire and get inspired. Time to write your story.
n°2267132
nraynaud
lol
Posté le 06-10-2015 à 15:16:55  profilanswer
 

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:
 

Code :
  1. this.get('controller.shapes.content').addArrayObserver({
  2.                     arrayWillChange: function (observedObj, start, removeCount, addCount) {
  3.                         for (var i = start; i < start + removeCount; i++)
  4.                             outlinesViews[i].destroy();
  5.                         outlinesViews.replace(start, removeCount, []);
  6.                     },
  7.                     arrayDidChange: function (observedObj, start, removeCount, addCount) {
  8.                         var newItems = [];
  9.                         for (var i = start; i < start + addCount; i++)
  10.                             newItems.push(wrapShape(observedObj[i]));
  11.                         outlinesViews.replace(start, 0, newItems);
  12.                     }
  13.                 });
  14.                 this.get('controller.shapes').forEach(function (shape) {
  15.                     outlinesViews.push(wrapShape(shape));
  16.                 });


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


---------------
trainoo.com, c'est fini
n°2267139
youmoussa
Ecrou-vis
Posté le 06-10-2015 à 15:46:17  profilanswer
 

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.


Message édité par youmoussa le 06-10-2015 à 15:48:43
n°2267144
nraynaud
lol
Posté le 06-10-2015 à 16:27:06  profilanswer
 

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.


---------------
trainoo.com, c'est fini
n°2267157
nraynaud
lol
Posté le 06-10-2015 à 17:59:39  profilanswer
 

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/


---------------
trainoo.com, c'est fini
n°2267200
youmoussa
Ecrou-vis
Posté le 07-10-2015 à 06:33:24  profilanswer
 

nraynaud a écrit :

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.


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

n°2267201
youmoussa
Ecrou-vis
Posté le 07-10-2015 à 06:34:53  profilanswer
 

nraynaud a écrit :

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/


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

n°2267231
nraynaud
lol
Posté le 07-10-2015 à 14:15:36  profilanswer
 

youmoussa a écrit :


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


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

youmoussa a écrit :


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


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.


---------------
trainoo.com, c'est fini
n°2267236
nraynaud
lol
Posté le 07-10-2015 à 14:58:07  profilanswer
 

Code :
  1. orderedOperations: Ember.computed.sort('operations', 'operationsOrderProperty'),
  2.             enabledOperations: Ember.computed.filterBy('orderedOperations', 'enabled', true),
  3.             computingEnabledOperations: Ember.computed.filterBy('enabledOperations', 'computing', true),
  4.             hasNoComputingOperations: Ember.computed.empty('computingEnabledOperations'),
  5.             hasEnabledOperations: Ember.computed.notEmpty('enabledOperations'),
  6.             canSendProgram: Ember.computed.and('hasNoComputingOperations', 'hasEnabledOperations'),


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.

Message cité 2 fois
Message édité par nraynaud le 07-10-2015 à 15:01:12

---------------
trainoo.com, c'est fini
n°2267342
youmoussa
Ecrou-vis
Posté le 08-10-2015 à 16:54:58  profilanswer
 

nraynaud a écrit :


cool, t'as des gens pour répondre à mes questions sur ember aussi ?
 
1) comment on scrolle à l'élément courant d'une liste en rentrant dans une route (c'est souvent lié au rechargement de la page)
2) comment est-ce qu'on détecte qu'on est plus dans une route ?
3) comment on gère les évènements sur window.
4) comment on gère ces putains d'observateurs qui fire pas?
5) comment on gère ces putains d'observateurs qui firent plusieurs fois de suite?
6) comment on gère la crise entre ember, ember-data et ember-fire, y'a toujours un bug ou un truc non-supporté, mais on sait pas qui est responsable de quoi et y'a jamais de message d'erreur, juste des comportements chelous (j'ai passé 3h sur un problème du style ce matin, je sais pas qui est responsable, mais y'avait pas de message d'erreur et une interface en rade).


 
 
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.. ) ?

n°2267345
nraynaud
lol
Posté le 08-10-2015 à 17:18:54  profilanswer
 

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.


---------------
trainoo.com, c'est fini
n°2267347
youmoussa
Ecrou-vis
Posté le 08-10-2015 à 17:28:04  profilanswer
 

nraynaud a écrit :

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

n°2267350
nraynaud
lol
Posté le 08-10-2015 à 17:33:55  profilanswer
 

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


---------------
trainoo.com, c'est fini
n°2267447
youmoussa
Ecrou-vis
Posté le 09-10-2015 à 18:29:07  profilanswer
 

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?

n°2267448
youmoussa
Ecrou-vis
Posté le 09-10-2015 à 18:31:26  profilanswer
 

nraynaud a écrit :

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


 
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

n°2267476
nraynaud
lol
Posté le 10-10-2015 à 04:52:44  profilanswer
 

youmoussa a écrit :

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?


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 ( [:pingouino] 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.


---------------
trainoo.com, c'est fini
mood
Publicité
Posté le   profilanswer
 

 Page :   1  2  3  4  5  6  7  8  9  10  11

Aller à :
Ajouter une réponse
 

Sujets relatifs
Comment créer un site web qu'on peut gérer avec un CMS après ?créer un fichier zip et le télécharger
Quelle solution pour créer une base de données ?Besoin d'une personne pour me créer une page accès membre.
Créer une page web html avec zone pour laisser un commantairecréer un rapport xml avec les outils Blindeelephant, waffit
[RESOLU] Créer un CSV à partir d'une chaîne en phpApplications bloquées par Java
Créer un site e-commercecréer son site en 10 minutes ?
Plus de sujets relatifs à : Ember.js - Framework JS - Ember Octane disponible !


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR