Reprise du message précédent :
Il suffit de lire les tests pour savoir comment utiliser les events
 
https://github.com/emberjs/data/blo [...] est.js#L21

et à la sérialisation (pour envoyer au serveur, disons), il va bien lire le cache ? et à la dé-sérialisation il va bien tenir compte de la valeur de l'utilisateur et pas celle calculée ?
 

'tain en fait j'ai d'autres endroits où ça marche. Je dois avoir un bug secondaire. En plus l'explorateur Ember est dé-synchronlsé de ma vue, y'a un autre problème
 
'tain la nuit entière à essayer de passer 3 objets vers ember-data.

 
Les CPs ne sont pas sérialisées par défaut, seuls les propriétés utilisant `DS.attr` le sont.
 
Tu peux écrire un sérialiseur pour ce modèle si tu veux obtenir ce genre de comportement.
 

 
C'est dispo dans une branche ce code ?

J'ai fait un JsBin pour démontrer en quoi il est en général plus intéressant d'utiliser une CP plutôt qu'un observer
 
http://emberjs.jsbin.com/gibifatika/1/edit
 
Au démarrage, l'observer et la CP ont été éxecuté le même nombre de fois.
 
Mais quand on utilise le bouton qui modifie plusieurs fois la propriété dont dépend l'observer et la CP, on voit que la CP est plus économique.

Je pense que je vais rester avec mon champ et ses listeners, parce que je vois pas l'apport des computed properties, par contre je vois ce que j'y perds en clarté et en sérialisation par défaut.
 
 
c'est sur ma working copy pour l'instant.
 
Et puis là c'est vraiment le merdier, il faudrait s'assoir côte à côte parce qu'il y a 30000 trucs qui marchent pas, donc avoir le code sans savoir sur quoi je focus servirait pas à grand'chose.  
 
Les fixtures semblent avoir un problème (, je sais même pas comment c'est possible qu'un truc aussi simple ne marche pas, j'ai dû faire une toute petite erreur et y'a un nom qui matche pas un truc et du coup le truc est pas reconnu mais fiat pas d'erreur), les events j'arrive pas à les faire marcher (pareil pas d'erreur) et puis ça a niqué les routes, mais bon, c'est peut-être évident j'ai pas encore regardé, vu que sans modèle c'est pas la peine de se faire chier à regarder les mécanismes d'interaction.

Ah ben tu peux venir sur SF. On ira manger une salade de kale en hors d'oeuvre de notre repas gluten free

Je répète, ca marche pas très bien le FixtureAdapter.

Tu dois voir des erreurs dans l'onglet Promise de l'inspecteur, j'ose espérer
 
Les promises, c'est un peu la merde pour ça.

Je t'invite à implémenter un global error handler aussi

http://emberjs.com/guides/understa [...] production

Bon, dodo pour moi

Visucam.Shape.reopenClass({
            FIXTURES: [
                {id: 1, definition: wabble.getEccentricShape()}
            ]
        });
        Visucam.Operation.reopenClass({
            FIXTURES: [
                {id: 1, name: 'Eccentric Hole', outline: 1, job: 1}
            ]
        });
        Visucam.Job.reopenClass({
            FIXTURES: [
                {id: 1, toolDiameter: 2, operations: [1], shape: [1]}
            ]
        });

y'a un bug évident là ?

dans l'inspecteur ember il voit 1 job, 0 shape, 0 operation.
quand je vais explorer le job, dans son hasMany "operations" y'a une opération dedans mais qui possède le nom par défaut et non les paramètres de la fixture (genre il a pas accroché les id). Et son hasMany "shapes" a une shape aussi, et vide aussi.
l'opération fantôme et la shape fantôme ont un ID de "1".

quand je modifie les IDs dans la fixture du job genre 'operations: [10]', l'opération fantôme a bien l'ID demandé, mais elle a pas les paramètres précisés dans sa fixture.

une petite exploration du job dans l'inspecteur:

(le tool diameter est bien celui de la fixture, donc la seule fixture qui marche c'est celle du job)

var attr = DS.attr;
 
    var Shape = DS.Model.extend({
        definition: attr('string')
    });
 
    var Operation2 = DS.Model.extend({
        name: attr('string', {defaultValue: 'New Operation'}),
        type: attr('string', {defaultValue: 'SimpleEngravingOperation'}),
        outline: DS.belongsTo('shape'),
        job: DS.belongsTo('job'),
        installObservers: function () {
            var properties = Operations[this.get('type')].properties;
            var _this = this;
            Object.keys(properties).forEach(function (key) {
                _this.addObserver(key, _this, _this.computeToolpath)
            });
        }.observes('type').on('init'),
        uninstallObservers: function () {
            var properties = Operations[this.get('type')].properties;
            var _this = this;
            Object.keys(properties).forEach(function (key) {
                _this.removeObserver(key, _this, _this.computeToolpath)
            });
        }.observesBefore('type'),
        computeToolpath: function () {
            Operations[this.get('type')]['computeToolpath'](this);
        }.observes('type', 'job.toolDiameter', 'job.safetyZ').on('init')
    });
 
    var Job2 = DS.Model.extend({
        safetyZ: attr('number', {defaultValue: 5}),
        toolDiameter: attr('number', {defaultValue: 3}),
        toolFlutes: attr('number', {defaultValue: 2}),
        surfaceSpeed: attr('number', {defaultValue: 200}),
        chipLoad: attr('number', {defaultValue: 0.01}),
        feedrate: attr('number', {defaultValue: 100}),
        speed: attr('number', {defaultValue: 24000}),
        startPoint: attr(null, {defaultValue: new util.Point(0, 0, 10)}),
        operations: DS.hasMany('operation', {
            inverse: 'job'
        }),
        shapes: DS.hasMany('shape'),
        deleteOperation: function (operation) {
            this.get('operations').removeObject(operation);
        },
        findOperation: function (id) {
            return this.get('operations').findBy('id', Number(id));
        },
        transitionTravels: function () {
            var operations = this.get('operations');
            var travelBits = [];
            var pathFragments = [];
            var endPoint = null;
            operations.forEach(function (operation) {
                pathFragments.pushObjects(operation.get('toolpath'));
            });
            if (pathFragments.length) {
                var prefix = new tp.GeneralPolylineToolpath();
                prefix.pushPoint(this.get('startPoint'));
                prefix.pushPoint(pathFragments[0].getStartPoint());
                travelBits.push(prefix);
                for (var i = 0; i < pathFragments.length; i++) {
                    endPoint = pathFragments[i].getStopPoint();
                    var travel = new tp.GeneralPolylineToolpath();
                    travel.pushPointXYZ(endPoint.x, endPoint.y, endPoint.z);
                    travel.pushPointXYZ(endPoint.x, endPoint.y, this.get('safetyZ'));
                    if (i + 1 < pathFragments.length) {
                        var destinationPoint = pathFragments[i + 1].getStartPoint();
                        travel.pushPointXYZ(destinationPoint.x, destinationPoint.y, this.get('safetyZ'));
                    }
                    travelBits.push(travel);
                }
                var suffix = new tp.GeneralPolylineToolpath();
                suffix.pushPoint(travelBits[travelBits.length - 1].getStopPoint());
                suffix.pushPoint(this.get('startPoint'));
                travelBits.push(suffix);
            }
            return travelBits;
        }.property('operations.@each.toolpath.@each'),
        createOperation: function (params) {
            var operation = this.store.createRecord('operation', params);
            operation.set('job', this);
            this.get('operations').pushObject(operation);
            return  operation;
        },
        createShape: function (def) {
            var shape = this.store.createRecord('shape', {definition: def});
            this.get('shapes').pushObject(shape);
            return shape;
        },
        didCreate: function () {
            this.updateSpeed();
            console.log('didCreate')
        },
        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'),
        updateFeedrate: function () {
            var speed = this.get('speed');
            var chipLoad = this.get('chipLoad');
            var toolFlutes = this.get('toolFlutes');
            this.set('feedrate', Math.round(speed * chipLoad * toolFlutes));
        }.observes('toolFlutes', 'chipLoad', 'speed'),
        getJson: function () {
            var test = $.extend({}, this);
            return JSON.stringify(test, function (key, value) {
                if (['concatenatedProperties', 'isDestroyed', 'isDestroying'].indexOf(key) != -1)
                    return undefined;
                return value;
            });
        },
        computeSimulableToolpath: function (travelFeedrate) {
            var operations = this.get('operations');
            var feedrate = this.get('feedrate');
            var travelBits = [];
            var pathFragments = [];
            var endPoint = null;
            operations.forEach(function (operation) {
                pathFragments.pushObjects(operation.get('toolpath'));
            });
            var startPoint = this.get('startPoint');
            var position = startPoint;
 
            function travelTo(point, speedTag) {
                travelBits.push({
                    type: 'line',
                    from: position,
                    to: point,
                    speedTag: speedTag == null ? 'rapid' : speedTag,
                    feedRate: speedTag == null ? travelFeedrate : feedrate});
                position = point;
            }
 
            var safetyZ = this.get('safetyZ');
            // it could happen that the cycle be started from a position that is lower than the start point
            // for example after doing the Z zeroing, the user might leave the tool just a few mm over the stock
            // or in a hole, it would be unsafe to travel from there.
            var safeStartPoint = new util.Point(startPoint.x, startPoint.y, Math.max(startPoint.z, safetyZ));
            if (pathFragments.length) {
                travelTo(safeStartPoint);
                travelTo(pathFragments[0].getStartPoint());
                for (var i = 0; i < pathFragments.length; i++) {
                    var fragment = pathFragments[i];
                    fragment.forEachPoint(function (x, y, z) {
                        travelTo(new util.Point(x, y, z), 'normal');
                    });
                    endPoint = fragment.getStopPoint();
                    travelTo(new util.Point(endPoint.x, endPoint.y, safetyZ));
                    if (i + 1 < pathFragments.length) {
                        var destinationPoint = pathFragments[i + 1].getStartPoint();
                        travelTo(new util.Point(destinationPoint.x, destinationPoint.y, safetyZ));
                    }
                }
                travelTo(safeStartPoint);
            }
            for (i = 0; i < travelBits.length - 1; i++) {
                var previous = travelBits[i].to;
                var next = travelBits[i + 1].from;
                if (previous.sqDistance(next))
                    console.error('continuity error', i, travelBits[i], travelBits[i + 1]);
            }
            return travelBits;
        }
    });

(toutes les promises de l'inspecteur sont fulfilled)

bon, presque tout marche.
 
Est-ce qu'il y a moyen de faire chercher tout un sous-graphe à Ember data, sans promise au milieu et sans truc asynchrone, juste un putain de graphe complet, normal ?

https://github.com/emberjs/ember.js [...] on_view.js
'tain j'aurai besoin d'une classe qui contienne 90% du code de ce fichier, sans tout le merdier associé au DOM, c'est dommage pas l'avoir sorti.
 
un truc qui prend une classe en paramètre, fait create() pour les éléments qui rentrent, fait destroy() pour les éléments qui sortent et c'est tout.

j'y comprends rien aux embedded records.

J'ai un Job qui a une liste d'operations et une liste de shapes. Chaque operation a un pointeur vers une shape. Je veux embedder les operations et les shapes dans le Job (ma base est une base hiérarchique, du coup, c'est comme si job était un document, tous ses éléments sont sous son noeud).

J'ai fait ça:

ça me donne ça:

sauf qu'à la deserialisation, il arrive pas à se souvenir que les shapes sont pas dans une table à part, mais dans le job, et qu'il faut aller les chercher là-bas.

Y'a une technique pour lui dire ?

truc de fou, en fait il dé-sérialize dans l'ordre dans lequel c'est défini dans la classe, du coup il faut trier soi-même dans l'ordre des dépendances. Là je les avais mise avec operations d'abord et shapes ensuite. Du coup il dé-sérialisait une opération et allait chercher le shape correspondant dans le store, ne trouvait rien et allait voir sur le serveur si y'avais pas une "table".

en fait c'est la pire réponse possible.
ça me dit pas où est enregistré le container, d'où il est visible et où je peux utiliser "needs" .
 
qu'un container est une hashmap, merci, j'ai assez joué avec. c'est les retarderies spécifiques à Ember qui m'intéressent.

 
Désolé si j'essaie de répondre en donnant de bonnes pratiques plutôt que de favoriser la bidouille
 
Ben "needs", c'est uniquement sur les contrôleurs.
 
Tu peux tricher et avoir accès au container via App.__container__, mais si le nom de la variable est un peu tordu, c'est justement pour montrer que ce n'est pas bon signe si tu l'utilises dans ton code.

 
Je pense qu'il y a un soucis dans ton code ou un bug dans ED, car ton idée initiale sur le fonctionnement me semble correcte.
 
Il n'y a aucune raison pour accéder au Shape a partir de l'opération pendant la deserialization. Tu as marqué cette relation asynchrone, donc ED ne devrait faire le lookup que lorsque tu fais un truc du genre "job.operations[0].shape" ( c'est un peu du pseudo code )

ça fait 20 ans que je développe, j'ai une certaine idée des "bonnes pratiques"
 
Et je crois pas que ré-implémenter les containers lourds en moins bien en fasse partie en fait

 
Je sais pas, je me contente de lire ton code
 
Tu peux faire une PR pour améliorer les choses sinon

le code d'un proto d'apprentissage ? Intéressante idée.
 
J'y comprends rien au système de base, donc avant de faire une PR y'a des millénaires. J'essaye de soumettre des PR utiles.
Enfin surtout j'en ai plein le cul d'ember, je sais pas encore si je vais le virer, parce que je vois pas en quoi autre chose sera plus simple à apprendre, mais c'est vraiment le syndrome du beau logo et agressivité sur twitter et franchement rien de transcendant en-dessous. C'est du java swing inavigable et sans le génie des mecs de codehaus ou de jgoodies.
Plus j'en apprends et moins je suis impressionné.

J'essaie d'y mettre du mien, mais parler d'agressivité sur twitter etc quand on voit ton comportement ici, c'est pas facile tous les jours je t'assure.
 
J'ai rien a gagner a t'aider. Pourtant j'essaie de le faire sur mon propre temps, parce que je pense qu'on peut faire beaucoup de choses avec le framework ( quand on voit certaines applis chiadées, c'est quand même impressionnant), et que ce sont les outils du futur.
Du coup comprendre où sont les problèmes ( documentation et/ou limitation technique ) m'intéresse en tant que contributeur.
 
Mais 90% de tes interventions ici ou ailleurs, c'est pour dire que X ou Y c'est de la merde... C'est fatiguant et ça donne pas envie de t'aider.

hum ok, tu veux comprendre où sont les problèmes, mais sans qu'on les pointe du doigt.
 
Je pense que le logo et l'arrangement de couleurs sur le site sont sympas. ça t'aide ? tu te sens mieux ?
 
Quand à savoir si je suis quelqu'un qui n'hésite pas à soulever les points négatifs ? oui. Et alors ? C'est comme ça que je suis, je suis pas un bisounours.
 
Je vends pas ma soupe comme si elle allait sauver le monde, et quand je vois quelqu'un qui le fait alors je me fais un malin plaisir à relever les merdes passées sous silence dans le tuto. J'en ai plein le cul de la pub sans substance des mecs dont le langage ou le framework va sauver le monde, et quand je me pointe pour l'utiliser parce que bon, il faut bien en choisir un, c'est Beirut autant que chez le voisin. Moi j'ai plus rien à vendre, mon projet est pas en état d'être releasé et c'est bien comme ça, mon dernier projet est hors-ligne, ça m'évite d'être comme tous ces cons dont la dernière création va sauver l'Afrique. J'ai plus d'employeur et au moins je pousse pas le projet de l'un de ces crétins qui veut être au-dessus de la meute.  
 
Surtout qu'il y a un léger problème d'alignement des objectifs quand tous les committeurs d'un framework sont consultants sur la chose, ils ont intérêt à ce qu'un max de monde se lance dedans, mais ait besoin d'aide professionnelle par la suite. Et ça donne des phrases un peu bizarres genre "sur mon propre temps", t'en connais beaucoup des gens payés pour être ici ? Ma PR que Stefan Penner a mergé hier il faut que j'aille réclamer de la thune ? Moi je suis pas consultant sur les rares projets open source sur lesquels j'envoie des PR, j'ai rien à vendre.

J'ai des promises, c'est cool, c'est jeune, tout ça, est-ce qu'il y a un système pour intégrer un stop et un rapport de progression ?

J'essaye de migrer un CRM vers une appli ember (backend en PHP/Symfony). Pour l'heure j'en suis juste à l'étape de la gestion de la connexion des utilisateurs avec ember-simple-auth.

 
Ça fait pas partie de la spec.  
 
https://promisesaplus.com
 
Tu dois pouvoir avoir le contrôle sur l'événement asynchrone pour obtenir ces infos et arrêter le processus toi même.

 
Hello,
 
Quelle type d'authentification utilises tu avec ton backend?

OAuth2.

Ça doit se faire relativement simplement du coup  

Oui
Je m'attaquerai au cœur de l'appli en janvier

ok, j'ai un truc super-indirect, accrochez-vous.
 
J'ai un modèle ember data:

var JobSummary = DS.Model.extend({
            name: attr('string', {defaultValue: 'Unnamed Job'}),
            job: DS.belongsTo('job', {inverse: 'jobSummary', async: true})
        });

 
il sert juste à indexer les jobs pour pouvoir présenter une liste de jobs sans ré-hydrater les jobs (d'où le async). Je sais pas faire mieux avec firebase.
 
dans le template j'ai:

et le this.job ré-hydrate le modèle (pour chaque job) et j'ai perdu.
Est-ce qu'il y a une feinte pour aller chercher l'id qui est sur un "belongsTo" sans ré-hydrater le modèle, et construire l'url et rien ramener de la base tant que c'est pas cliqué ?

pour l'instant j'ai utilisé  

 
(jobSummary._data.job.id)
Je sais pas ce qui serait une méthode officielle.

pourquoi ré-hydrater? Ils sont déjà chargés ?

sur la page d'accueil de l'utilisateur, j'ai la liste de ses jobs:
http://i.imgur.com/78TfWWe.png

pour afficher cette liste, j'avais:

Visucam.IndexRoute = Ember.Route.extend({
            model: function () {
                if (this.get('firebase.isAuthenticated'))
                    return this.store.find('job');
                return null;
            }
        });

et ce truc ré-hydrate tous les jobs de l'utilisateur, ce qui prend un temps fou et télécharge une tonne de bordel (des modèles 3D entre autre).

du coup j'ai dé-normalisé avec une entité jobSummary:

var JobSummary = DS.Model.extend({
            name: attr('string', {defaultValue: 'Unnamed Job'}),
            job: DS.belongsTo('job', {inverse: 'jobSummary', async: true})
        });

Je procederais différemment. Tu n'as pas 2 routes distinctes pour job et job summary, non ?

Si tu n'as qu'une route, utilise le job summary dans le link-to.

Ensuite dans `afterModel` de JobSummaryRoute, retourne simplement `model.get('job')`

Petit update du début d'année
 

• Emberconf qui a lieu début mars à Portland, OR est complet. Qqn y va ?
• Proposition pour Ember 2.0 avec un chemin clair pour upgrader les applis existantes (contrairement à Angular 2.0 qui va forcer la réecriture complète des applis )
• HTMLBars qui va arriver avant 2.0

Questions tournées vers Youmoussa, mais je suis intéressé par tous les avis
 
Tu utilises / recommande Ember Data ? Sinon, quoi d'autre et dans tous les cas, pourquoi ?
 
Niveau Ember CLI, pourquoi Broccoli plutôt que Gulp, Grunt ou simple un script NPM ?
 
En bonus, tu as un avis sur cet article (on se penche seulement maintenant sur la question de toolchain) ?

J'utilise Ember Data.

Les alternatives sont Ember Model ou de tout gérer à la main( Zendesk avait mis autre chose en open source, je ne me souviens plus du nom ).

Autant Ember a atteint un niveau de maturité qui rend son utilisation très agréable, autant Ember Data peut encore être très "work in progress". Ce que ED cherche à faire est très compliqué, ce n'est pas pour rien qu'il n'y a pas vraiment d'alternatives/équivalent ni pour Ember, ni dans les frameworks concurrents.
Et la documentation est quasi inexistante

C'est pourtant bien puissant et marche bien dans beaucoup de cas. Je tiens à préciser aussi qu'un gros effort a été fait depuis 1 an sur ce projet, et que malheureusement pour moi, je suis coincé sur un projet depuis 6 mois qui utilise une ancienne version. Mais les dernières releases fonctionnent apparemment beaucoup mieux car certains problèmes architecturaux ont été résolus et un effort sur les performances a été fait.

Je l'utilise sur tous mes projets, mais je sais aussi que je peux rentrer dans le code si besoin. Encore une fois, la communauté est très réactive, faut pas hésiter à demander sur stackoverflow, discourse ou sur IRC quand tu rencontres un problème ( ou ici ).

Pour le développement, il n'y a pas de question à se poser, Ember-CLI est la voie royale.
 
Comme beaucoup de choses dans Ember, le but n'est pas de réinventer tout, mais d'appliquer au js/navigateur les concepts éprouvés côté serveur. Le constat qui a été fait est qu'il n'existait globalement que des task managers pour js ( Grunt ) et rien d'équivalent/performanand à l'asset pipeline qui avait fait la joie des développeurs Rails à sa sortie.
 
npm est à la base un package manager comme bower. Ce n'est pas fait pour "builder" une grosse appli js ( avec beaucoup de fichiers et de type de fichiers différents ).
 
L'objectif de Broccoli, est de dire qu'il n'est pas acceptable pour un dev d'attendre 30 secondes que qqch regenere les fichiers à chaque fois que tu sauvegardes une modification ( et que tu dois raffraichir ton navigateur plusieurs fois jusqu'à ce soit correctement chargé ).

quelqu'un a une solution complète pour les numberfields ?
 
http://stackoverflow.com/questions [...] ber-fields
ici on voit qu'ils on mis les attributs en HTML, mais ils ont pas mis le parseFloat() qui va avec, et je galère à le faire (et si ça gérait les infini, ça serait cool)
 
j'ai fait ça: https://github.com/nraynaud/webgcod [...] i/views.js
mais en fait c'est pas suffisant, parce que "value" et "numericValue" se désynchronisent, j'arrive pas à le faire correctement.

Petite question à propos de l'instrumentation.
 
Pour une appli très simple pour laquelle je ne souhaite pour le moment pas mettre en place d'AMD / ES6 module / whatever, j'ai l’impression que mon seul choix pour les templates est de tout faire vivre dans le index.html.
 
Ma question se résume à : je veux mettre mes templates HTMLBars (Ember 1.10) dans des .hbs plutôt que tout dans l'index.html, quel choix s'offre à moi pour simplement générer un templates.js sans pour autant devoir mettre en place de l'AMD ?
 
Ember CLI demande de se conformer à la syntaxe d'un resolver ES6, en plus d'être une usine à gaz buggée sous Windows et qui m'impose d'autres choix architecturaux. Le plugin gulp-htmlbars se rapproche le plus de mon besoin, mais la configuration ciblant Ember me demande là encore de me conformer à une syntaxe ES6 de ce que j'ai pu comprendre de l'exemple d'ember-rocks.
 
Je rate quelque chose ?

Tu veux faire quoi en fait ?