Reprise du message précédent :

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.

nan, mais j'ai lu la doc, j'ai mis mon deactivate là où il fallait, j'ai vérifié dans le debugger qu'il sortait bien de la route, et il était pas appelé.
J'ai passé 2-3h sur le problème avec google et des tests, je cherche une aide un peu plus avancée.

et dans le 4) évidemment, on peut pas simplement toujours déclencher la première lecture sur .on('init'), des fois c'est .on('didLoad'), et je suppose que parfois c'est autre chose.

 
Je me doute que des fois ma réponse est un peu simpliste mais

• quand on fait du dépannage à distance, il faut souvent éviter d'assumer certaines choses
• je suis sur que certaines personnes lisent ce topic, ca a un but éducatif

 
Ca devrait marcher.

Si tu me donnes les instructions pour reproduire le(s) problème(s), je veux bien jeter un oeil.

ouch, laisse-moi retrouver le contexte. tu peux faire un pull pendant ce temps.

ok, dans jobModel.js ligne 27, rajouter les computed properties qui manquent.
 
et dans le bas de jobController.js function syncCanSendProgram() tu as le doit de faire tout ce que tu veux pour que le message parte au bon moment (je te propose de vérifier à coup de console.log(), et tu as le droit d'envoyer plus de messages que nécessaire, c'est pas grave à cet endroit)
 
une opération "enable" ça se gère par les petites cases à cocher en bas à gauche de cette copie d'écran:  
https://raw.githubusercontent.com/n [...] ockets.png
 
et pour avoir une opération en cours de calcul bien long, je te suggère simplement d'utiliser une opération pocket c'est ce qu'il y a de plus lent ("+" à côté de shape, puis "+" à côté d'opération, et tu peux ralentir le temps de calcul en utilisant un outil plus petit ou une shape plus grosse)
 
Le principe général c'est que si y'a aucune opération sélectionnée ou si au moins une des opérations sélectionnées est en cours de calcul, 'canSendProgram' doit être faux et l'observateur doit envoyer un message, et il doit envoyer un message quand il redevient vrai.
 
(bonus point is tu arrives aussi à élégamment envoyer un message quand y'a aucun job à l'écran et donc on a aucun programme à envoyer à la machine)

on dirait que même un truc aussi simple que  

computingOperations: Ember.computed.filterBy('operations', 'computing', true),
            computing: Ember.computed.notEmpty('computingOperations'),

ça marche bien au init, mais plus tard dans la vie de l'appli, les même quand y'a une opération en cours de calcul, le computing change pas (là je l'utilise par un {{#if}} dans un template, donc j'ai aucun observateur explicite, toute la chaîne est par ember).

j'essaye de migrer à la dernière version voir si elle bugge moins, mais je suis coincé avec une deprecation:
http://emberjs.com/deprecations/v1 [...] rs-helpers

j'ai un Ember.Handlebars.helper()
Et je sais pas comment traduire leur consigne en ES5 sans ember-cli.

https://github.com/emberjs/ember.js [...] os.js#L147
et
https://github.com/emberjs/ember.js [...] ros.js#L26
 
J'ai un peu de mal à capter le code, mais ça veut dire, que Ember.computed.map() repasse sur tout le tableau quand la moindre valeur change ? y'a pas un truc qui surveille élément par élément ?

J'ai oublié comment ça se lance ton appli, tu peux me rappeler ?

`/webapp/visucamTest.html`, c'est bien ça ?

Tu dois vouloir un truc genre reducedComputed

https://github.com/emberjs/ember.js/pull/2711

Ca a été viré il me semble avec Glimmer

Je te déconseille de faire le saut 1.7 -> 2.1 d'un coup.

Et il faudrait savoir ce qui bugue avant d'upgrader.

yep

j'ai rollbacké pour l'instant.

J'avoue ne pas trop comprendre comment reproduire le problème pour le moment. C'est pas super clair sur ce que je dois faire exactement ( je connais pas ton appli donc les histoires d'opérations longues sans valeurs précises, ça ne me parle pas ) et à quel moment tu t'attends à quoi.
 
C'est quand je check/uncheck une opération ?

 
dans cette séquence, à chaque fois qu'il y a un pinion qui tourne sur une opération (en bas à gauche), il devrait y avoir un pinion qui tourne juste à côté de "name" en haut à gauche.
 
le template avec le "name" et le petit pinion est là:
https://github.com/nraynaud/webgcod [...] ob.hbs#L17
 
computing de job est là:
https://github.com/nraynaud/webgcod [...] del.js#L29

j'imagine que faire "job.get('operations.@each.attribute')" ça marche pas ? il faut faire le map() à la main ?

job.get('operations').mapBy('attribute')

merci.

J'ai commencé à regarder le code, mais le manque de connaissance dans ce que ça fait combiné à l'absence de tests rend le travail difficile.
 
Idéalement, l'application serait testée et tu m'écrirais le test qui foire
 
Il y a une tripotée d'observers ( je parle pas de CP la ) qui peuvent théoriquement compromettre le calcul des CPs. Je ne sais pas par quel bout commencer.

C'est marrant la dernière fois que j'ai fait une rando, idéalement y'aurait pas eu de neige, mais dans la réalité c'était la merde totale. et je pouvais plus remonter quand j'ai vu qu'il y avait de la merde blanche à passer au-dessus des lacs.
 

les versions de ember data et ember sont lockées ensemble ?

Je lis pas mal de messages passifs agressifs envers les observateurs dans les docs ember et ici.  
 
1) Comment est-ce que je peux créer un worker et lui envoyer un message ou émettre un message vers une window avec une bound property ? Parce que là les doubles updates ça devient insupportable, j'ai du Ember.run.debounce() partout pour essayer de limiter la casse, et j'ai laissé filer un double update qui aurait bien pu me planter la machine.
 
2) Et comment je peux gérer une property qui retourne une promise ?

 
Depuis la 1.13 et définitivement en branche 2.x oui, avec CLI.

 
1) tu veux sûrement remplacer le binding par une action. Tu utilises le binding pour mettre à jour l'UI, met quand tu changes la valeur, tu envoies une action plutôt que d'utiliser le double binding
 
2) tu sais utiliser RSVP.js ?

CLI est toujours pas sorti en 2.x je crois.

1) ça veut dire qu'au lieu d'observer simplement les éléments directement utiles à mon calcul, je dois remonter toute la chaîne de dépendance et aller voir tout ce qui vient de l'ui, et là aller planter une action?
 
2) ben je l'ai utilisé, mais dans le dos de ember. C'est là: https://github.com/nraynaud/webgcod [...] /models.js

rooh putain, jai trouvé ! je suis con \o/
 
"computing", il était truish mais pas toujours === true, j'utilisait tout et n'importe quoi pour faire le true, du coup les filterBy, ça se passait pas bien !
 

Saleté de JS

J'ai ça dans mon routeur

Visucam.Router.map(function () {
            this.resource('job', {path: 'jobs/:job_id'}, function () {
                this.resource('operation', {path: 'operations/:operation_id'});
                this.resource('shape', {path: 'shapes/:shape_id'});
            });
            this.resource('login', {path: 'login/:login_type'});
        });

 
quand je passe de #/jobs/-JyU5xRGYRxe40smF4gJ à #/
 
j'ai pas deactivate d'appelé dans JobRoute, c'est normal ?
J'arrive pas à capter le pb.
 

Visucam.JobRoute = Ember.Route.extend({
            actions: {
                willTransition: function (transition) {
                    window.postMessage({canSendProgram: false}, '*');
                },
                didTransition: function (transition) {
                    this.controllerFor('job').syncCanSendProgram();
                }
            },
            model: function (params) {
                var _this = this;
                return this.store.find('job', params.job_id).then(null, function (error) {
                    console.log('error', error);
                    if (error && error.stack)
                        console.log(error.stack);
                    _this.transitionTo('index');
                });
            },
            setupController: function (controller, model) {
                this._super.apply(this, arguments);
                this.controllerFor('job').set('currentOperation', null);
                this.controllerFor('job').set('currentShape', null);
            },
            trackPageLeaveAnalytics: function(){
                console.log('deactivate'); //<---- jamais appelé
            }.on('deactivate')
        });

Si je me rappelle bien, deactivate n'est pas un event mais uniquement une callback.

deactivate: function() {
  this.trackPageLeaveAnalytics();
}

edit, je confirme, c'est appelé comme ça

exit: function() {
        this.deactivate();
        this.teardownViews();
      },

là où `init` est à la fois une callback et un event par exemple

apply(this, this.init, args);
sendEvent(this, "init" );

merci, je vais voir ça, mais la doc est assez explicite:
http://emberjs.com/api/classes/Emb [...] deactivate
donc ça sent le léger pb de ce côté là.

je confirme qu'en callback ça marche, merci

Je pense que la documentation ne correspond pas à ta version. Ca a du être implémenté dans une version plus récente.

rah putain, probablement, oui

C'est pour ça que je pousse pour être au moins en 1.10 au boulot, c'est trop chiant sinon

'tain je sais pas dans quel piège j'ai été me foutre, je veux dé-charger les modèles inutiles quand on passe d'une route à l'autre, mais tous les debounce() et workers se réveillent quand l'objet a été déchargé, il va falloir noter tout ce qui est asynchrone et le butter ou l'attendre.

Je croyais qu'un des principes d'Ember était de permettre la mise à jour vers la version suivante dans le contexte d'un sprint

bouarf, moi je suis en cowboy dépressif tout seul à la maison, donc la notion de sprint c'est mort.
 
par contre, ça vaudrait peut-être le coup de mettre un lien vers une page dans les warnings de dépréciation, c'est parfois un peu ardu à capter.