Reprise du message précédent :

j'ai des libs qui veulent leurs polylignes sous forme de buffer de float32, j'en ai d'autres qui les veulent sous forme de tableau de {X,Y}, et d'autres sous forme de tableaux de tableaux (le points sont un tableau[x, y, z]).
 
donc j'ai trafiqué les points (en jouant sur le fait que [1] sera converti en ["1"] sur un objet), mais je peux pas trop trafiquer les polylignes elles-mêmes.

bah il reste quand même une bonne partie de mon ancienne équipe de Besac qui fait du ember. Mais ils avaient fait venir Tom Dale.

C'est en lecture seule?
 
J'imagine que le mieux dans ce cas c'est de créer un composant par type, qui se charge lui de faire la conversion.

 
Donc ce sont les mêmes
 
Je ne savais pas que tu bossais là bas. Tom était tout content de me raconter sa grande expérience du TGV pour finir à Besançon

j'ai démissionné quelques années avant qu'ils fassent du Ember (ou même du web tout court), mais quand ils l'ont fait venir, ils m'ont invité à venir le rencontrer. Donc je suis descendu de mon trou perdu (Montbéliard ) pour aller à mon ancien bureau.
Du coup le seul mec avec qui j'ai effectivement bossé c'est @sly7_7 (il était stagiaire à l'époque), Mike est arrivé après (le reste de l'équipe, je crois pas qu'ils soient actifs au niveau Ember).

question stupide, je vois que ember-precompile ne compresse pas le HTML dans ses templates, y'a moyen de le faire.
 
genre il génère des trucs comme ça:  

data.buffer.push("\n                </div>\n            </div>\n        </div>\n    </div>\n</div>\n<div id=\"drawing\">\n    " );

y'a moyen d'observer toutes les propriétés d'un objet en Ember ?
 
Et j'ai pas la liste à l'avance, voire même elle est dynamique (rapport à mon implémentation du choix du type).
 
Toutes les solutions de undo que je trouve sur le net supposent qu'on connaisse à l'avance la liste des propriétés à surveiller.

Tu peux le faire sur un POJO. Sur un Ember.Object ça semble plus délicat, surtout pour différencier les propriétés de la classe mère et celle de ton instance.
 
Ça a beau être dynamique, tu as un nombre limite de classes. Ça doit pas être la mort de maintenir un tableau de propriétés à observer par type.
 

je veux ça: ember-routing-linkto-target-attribute ça en est où ? je capte rien à ce que je google.
et si c'est pas dans la dernière stable, comment je peux contourner ?

c'est derrière un feature flag.
 
http://emberjs.com/guides/configur [...] ure-flags/
 
https://github.com/emberjs/ember.js [...] tures.json
 
Tu dois pouvoir t'en servir si tu utilises une 1.8 beta, et il faut l'activer si tu utilises la 1.7.
 
C'est pas dispo pour les versions précédentes.

merci

C'est pour gérer la redirection quand tu détruis une opération que tu veux ça ?

Je fais un code review, je te ferai une PR

non, c'est pour un éditeur de dessin qui serait dans une tab séparée, mais je suis pas sur finalement, ça sent l'interface à la con.

hop, j'ai fait la PR
 
https://github.com/nraynaud/webgcode/pull/1
 
Dis moi si j'ai peté qqch

Merci.
 
quand on remonte dans la route / après avoir été dans une opération, ça remet pas currentOperation à null, c'est pour ça que j'avais tout fait à la main au final.

Oups.
 
J'ai corrigé le code.

Bon, maintenant que j'ai lu le code, je pense pouvoir te proposer quelque chose pour le côté typage dynamique qui n'en est pas vraiment un.
 
Faut que je réfléchisse un poil plus.

Ok, merci. Si t'as le undo en tête au passage, ça serait cool

Je vais y réfléchir    
 
Il faut trouver un mécanisme générique tirant avantage des setters sur CP j'imagine, avec comme objectif de stocker la valeur avant modification.

Je verrais bien aussi tes différentes opérations définies dans leur propre classe au lieu de changer le type a la volée.

ben c'est ce que j'avais fait au début, mais je savais pas faire la combo de changement de type.

dans ember data, on peut mettre des méthodes sur les modèles ?

C'est un Ember.Object comme un autre, donc oui.
 
Je ne sais pas si tu veux parler de persistance a ce sujet.

bof, la relation avec la persistance est ténue, je m'attends pas à ce qu'il expédie du code, sa closure et sa stack sur la socket.
 
 
C'est juste que quand il ré-hydrate un objet, c'est plus pratique pour moi si c'est un vrai objet avec des méthodes qu'un de ces systèmes où t'as une structure pour stocker les données et tu dois mettre tes fonctions à côté. Je vois aucun exemple comme ça dans les docs de ember data, donc je me méfie.

'tain y'a tout qui prend des heures Ils ont même niqué les toString() pour pas qu'on puisse explorer le graphe d'objet depuis la console, le code est titanesque et à moitié magique, les trucs trouvés sur stack overflow marchent pas
 
comment je peux attraper le store (genre datatore) depuis l'extérieur de l'appli ? Je suis pas dans un objet je suis dans le contexte global.
 
genre la réponse à ça:
http://stackoverflow.com/questions [...] at-i-can-d

La bonne méthode pour passer le store c'est d'utiliser un initializer

http://emberjs.com/api/classes/Emb [...] itializers

Tu as le container, donc tu peux avoir accès au store avec

Après, si tu expliques un peu plus le contexte, il y a peut être un meilleur truc à faire

Merci, je vais regarder ça.

je suis sensé le trouver sur quel objet mon "container" ?
l'objet racine ("App" dans tous les exemples) n'a pas de méthode lookup dessus, pourtant y'a une propriété __container__ dessus.
 
je trouve pas la doc de container (enfin je sais pas à quelle classe ou mixin ou adapter ou whatever il appartient).
 
Je trouve pas la doc de la fonction lookup non plus (ni quelle classe la déclare), la boite de recherche du site va se perdre dans des minutes de meeting et autres release notes.

Apparemment, il n'y a pas de doc là dessus effectivement, donc le code et les tests serviront de doc
 
https://github.com/emberjs/ember.js [...] ntainer.js
 
https://github.com/emberjs/ember.js [...] er_test.js
 
 
 
Se servir du store de manière globale, c'est pour des tests ou pour un but précis? Accéder n'importe quoi de n'importe où, ca va souvent rarement dans le sens d'une bonne modularisation et ca rend l'écriture de test pénible.

je reviens là-dessus, parce que, surprise, c'est pas vraiment le cas (j'avais posé la question parce que je sentais le coup venir).
 
donc sur mon ember.object j'avais:

updateSpeed: function () {
                var toolDiameter = this.get('toolDiameter');
                var surfaceSpeed = this.get('surfaceSpeed');
                this.set('speed', Math.round(surfaceSpeed * 1000 / Math.PI / toolDiameter));
            }.observes('surfaceSpeed', 'toolDiameter').on('init'),

C'est une propriété dont on peu laisser le système calculer la valeur ou la définir à la main. Initialement la valeur est calculée.
 
sauf que quand j'appelle le store.createRecord() pour créer le record de ce type, le .on('init') se déclenche et ça provoque une erreur:

donc y'a une espèce de fenêtre de vulnérabilité où on peut pas changer des trucs (c'est évoqué là aussi : http://coryforsyth.com/2013/06/10/ [...] e-machine/ ).
 
donc mon impression c'est qu'il faut changer mon .on('init') en autre chose.  
 
Et là c'est un peu relou, basiquement quand un handler est mal déclaré, il se passe rien, il faut bidouiller jusqu'à tomber sur le bon.
 
 
ici :
https://github.com/emberjs/data/blo [...] es.js#L689
ça suggère qu'il existe un event nommé 'didCreate', j'ai essayé de déclarer .on('didCreate'), mais ça n'appelle pas la fonction , j'ai essayé de déclarer une fonction  

didCreate: function(){
 this.updateSpeed();
 console.log('didCreate');
}

sur le modèle, mais ça semble pas appelé
 
Bref, je suis un peu paumé, comme d'hab.
 
Il faut noter que la propriété calculée marche une fois le système démarré, c'est son initialisation qui ne marche pas.

Je vais faire mon sport du lundi et je jette un œil
 
Tu utilises encore un observer au lieu d'une CP car c'est utilisé par ta librairie 3D?

non, j'utilise un observer parce que je veux que l'utilisateur puisse changer ce que la machine a calculé.

ca n'a rien d'incompatible avec une CP

j'y avais pas pensé, genre une computed property dans laquelle on peut écrire avec un champ caché en-dessous ?

Pourquoi caché ? Il est censé changer la valeur comment l'utilisateur ?

http://nraynaud.github.io/webgcode [...] est.html#/
change le surface speed, ça change la vitesse de rotation. Mais tu peux changer la vitesse de rotation toi-même.
Pareil pour le feedrate, il peut être calculé à partir de la vitesse et du chipload, ou tu peux le définir directement.

En théorie, un truc dans le genre devrait marcher

Quand tu tapes à la mimine une valeur, tu es en mode setter.
Si `surfaceSpeed` ou `toolDiameter` changent, ca effectue le calcul ( partie getter de la CP ).

J'ai pas bien compris, si je lis la vitesse, j'ai toujours celle qui est calculée, au lieu d'avoir celle que l'utilisateur a saisie.
Et surtout ça m'explique pas comment j'utilise les events dans ember data.
 
Et entre temps je rencontre un autre problème  
'tain c'est le Vietnam.

updateSpeed: function () {
                var toolDiameter = this.get('toolDiameter');
                var surfaceSpeed = this.get('surfaceSpeed');
                this.set('speed', Math.round(surfaceSpeed * 1000 / Math.PI / toolDiameter));
            }.observes('surfaceSpeed', 'toolDiameter').on('init'),

didCreate: function(){
 this.updateSpeed();
 console.log('didCreate');
}

Ca devrait pas arriver, ce n'est pas exactement le même problème je pense. Le message d'erreur parle de "root.empty" pas de in flight.

Le problème avec in flight, c'est lorsque que le modèle est en attente d'une réponse du serveur. Il n'y a pas de logique pour résoudre un conflit, donc pour le moment ED te jette. Pour éviter ce genre de problème, il faut empêcher l'utilisateur de modifier l'enregistrement pendant ce laps de temps.

Rien qu'en lisant le code, je ne vois pas ce qui génère cette erreur, il faudrait que je debuggue pour te dire exactement le problème.

non, car ca tire avantage du cache des CPs.

Tu fais rien, et tu demandes la CP: elle n'est pas en cache, donc la fonction est appelée, tu tombes dans la partie getter.
La valeur te plait pas, tu tapes dans le champs, avec le binding, ca va faire un `set('speed', laNouvelleValeur)`. Tu tombes dans la partie setter qui ne fait rien de spéciale, et c'est `laNouvelleValeur` qui est mise en cache
Tu redemandes `get('speed')`, ca te renvoie direct la valeur du cache.
Tu changes `toolDiameter`, ca invalide le cache, sans recalculer la valeur. C'est uniquement lors du prochain accès que ce sera calculé.
Dans ce cas précis, c'est quand la vue se remet à jour. Et dans ce cas, la fonction associée est executée et renvoie la valeur du getter.

`on('didCreate')` aurait du marcher AMHA.

Il suffit de lire les tests pour savoir comment utiliser les events
 
https://github.com/emberjs/data/blo [...] est.js#L21