Reprise du message précédent :

 
Non
Getting Started, et ensuite je creuse.
 

(c'est vraiment être naïf de jeter un pavé de doc à la face des gens, on commence pas un apprentissage par lire un pavé, on commence par bidouiller et on lis progressivement des doc de référence sur des points de détails ou des techniques particulières)
 
 
http://ember101.com/videos/004-mas [...] et-linkto/
ici, il se passe quoi quand je clique sur une autre entrée niveau instances de détail ?
 
est-ce j'ai toujours la même instance de vue et la même instance de contrôleur, mais simplement le modèle du contrôleur est re-bindé sur le nouveau modèle (et tout se propage par observateurs) ? le contrôleur est détruit et un nouveau est créé, ou tout le monde part à la poubelle et est reconstruit, contrôleur et vue ?

 
Le Getting Started fait partie de la doc    (OK, redface is red)
Blague à part, s'il faut se fader 80% du site (un peu aride) avant de faire le premier tuto y'a peut-être un trou dans la raquette non ?
 
Le reste du GS m'a paru plutôt digeste, mais pour ce point de confusion je pense qu'il y a vraiment moyen d'améliorer les choses facilement.
 

 
en l'occurence, je ne parle pas de lire toute la doc avant de démarrer, mais de lire en plus la partie "Concepts". Il faudrait surement mettre plus ça en avant ( voir ca devrait être lu avant le Getting Started / Todos app ).
 

 
Les controlleurs à ce niveau sont des singletons, donc ils ne sont pas détruits autant que je sache.
 
Le modèle est assigné au controlleur et tout se propage via le binding. ( il faut que je reverifie pour être sur de ne pas dire de connerie là )

 
Ben je ne parle pas de lire 80% de la doc, mais 2 pages de plus    
 
Je comprends bien que ce n'est pas réaliste de lire un bouquin entier avant de proposer de passer à la pratique

te fais pas chier, je vais regarder alors.
c'est parce que je fais rien comme dans les tutos. Et toutes mes vues sont pas simplement des éditions de DOM à coup de templates, mais j'ai aussi des trucs en 3D qui nécessite d'écrire à la main le listener de changement de détail. (et en SVG je le fais aussi, j'ai pas trop envie de me tordre le cerveau à faire rentrer ma vue 2D dans le monde des templates, sachant que j'ai une lib SVG qui ignore Ember).

c'est assez courant d'utiliser svg/d3 avec Ember.

La bonne approche est généralement d'écrire des Components pour encapsuler les directives/primitives de ces librairies.

Je vais quand même chercher dans le code source l'endroit où le modèle est remplacé ( je reste sur de moi à 95% on va dire )

la vue, c'est sûr qu'elle dégage pas, y'a qu'un appel à "didInsertElement".

Ce serait très con d'avoir implementé le binding si c'est pour tout détruire/reconstruire quand on change de modèle  

bof, on peut pas faire tout mutable ou tout immuable, donc ils peuvent avoir tracé la ligne n'importe où (et ensuite être super agressifs dans leurs choix, fussent-ils à la cons, comme les observateurs pas appelés avant la première lecture).

j'ai une question par rapport au code maitre-détail:
(toujours le même http://jsbin.com/ijejap/1/edit )
 
ici il utilise 2 templates et d'une certaine façons le système colle le nom des routes avec le nom des templates (et encore, je sais pas comment il se démerde si y'a plusieurs {{outlets}}, par l'ordre dans la page?).
 
comment est-ce que je peux tout mettre dans le même template ?

tu ne peux effectivement pas avoir plusieurs outlets sans noms dans un meme template pour la raison que tu cites ( c'est ce que je tentais d'expliquer dans le "Comment les 2 routes s'emboitent ?" de mon post explicatif d'hier ).
 
Tu veux qu'une partie de la vue soit vide tant que tu n'as pas effectué une action ? J'aurai besoin de comprendre un peu plus à quoi doit ressembler ta vue en fonction de l'état de ton application.

template d'application:

<div class="operations">
    <ol>
        {{#each}}
            {{#link-to "operation" this}}
                <li>{{name}}</li>
            {{/link-to}}
        {{/each}}
    </ol>
</div>
<div class="currentOperation">{{outlet}}</div>

template "operation"

<strong>{{name}}</strong>

 
comme actuellement, il laisse l'endroit où se trouve {{outlet}} vide.
 

Et comment tu sélectionnes/deselectionnes l'opération qui doit être affichée ?

par l'url ?
http://localhost/~nraynaud/webgcod [...] erations/1
 
http://localhost/~nraynaud/webgcod [...] perations/
 
comme avant ?
ça reste une vue maître-détail, parfois on vire le détail (même si là j'en ai pas besoin, mais je veux comprendre comment tout faire en un seul template)

Tu sembles chercher a détourner le comportement de base du framework sans que je n'arrive a comprendre l'intérêt.
 
Pourquoi veux tu n'avoir qu'un template ?

Une réponse courte, serait de modifier une propriété 'opération' sur ton OperationsController que tu maintiendrais toi même.
 
Ça me semble être une mauvaise pratique.

je veux faire ça pour comprendre le mécanisme du merdier. Pour changer des bouts et voir ce qui change. j'essaye de construire une image mentale de ce que fait le framework et comment il marche. Et je dois avouer que pour l'instant ça a un sens assez limité au niveau des outlets, des routes et des templates.
J'imagine que le forcer à faire un truc qui sort des conventions de nommage oblige à exposer le mécanisme sous-jacent, et à voir un peu ce qui est caché.

(et j'en profite que t'es là parce que quand je serai tout seul, je vais me toucher la bite avec mes questions, donc j'ai intérêt à prendre de l'avance)

 
Je comprends plus ou moins, mais ça me semble plus logique de commencer a maîtriser les concepts d'un framework avant de chercher a s'en éloigner en tentant de compliquer l'implémentation.
 
Les conventions de nommage sont la pour assembler certaines pièces du puzzle ensemble.
 
Il existe des moyens de les contourner de manière "légale/officielle".
 
- en utilisant path dans ton router tu permet de dissocier l'url du nom de la route.
- en utilisant controllerName dans ta route tu as la possibilité de renommer ou d'utiliser un controlleur ne suivant pas la règle de nommage.
- en utilisant templateName dans une vue tu peux également ne pas nommer ton template selon la vue
 
Tu peux ensuite aller plus en profondeur et avoir ta propre implémentation de renderTemplate dans la route pour afficher quelque chose ne correspondant pas a la règle de nommage.
 
 
La règle de nommage est la pour te simplifier la vie. J'ai l'impression que parce que tu n'as pas lu cette partie, tu souhaites t'en affranchir.

 
Je serai toujours la ( au grand désespoir de certains )

J'ai lu la convention de nommage, mais c'est pas suffisant. Je trouve légèrement méprisant de dire "t'as pas lu" quand j'ai passé des heures à googler le merdier. Donc j'ai envie de répondre que la doc est de la merde parce qu'elle prescrit des pratiques sans expliquer les mécanismes en détail.
 
J'ai une vue qui va entre autre afficher le détail qui est en 3D, elle est pas templatisable (enfin elle est insérée une fois dans le template d'application au plus haut niveau et elle bouge plus, elle plante ses obsevateurs dans des contrôleurs et elle bouge plus en ce qui concerne le reste du monde). Elle va afficher à la fois des infos globales liées à la liste des opérations et le détail (par exemple la pièce finie ou au contraire le brut en transparence, et l'opération d'usinage sélectionnée par dessus en rouge sans transparence).
 
Je ne vois absolument pas comment coller ce modèle à la notion d'outlet ou de route. Et je ne changerai pas cette vue à court terme parce qu'elle est déjà utilisée dans 3 apps.
 

 
Je veux bien croire que la doc est perfectible, je trouve bizarre de dire "je veux pas lire un pavé" mais je veux qu'on m'explique "les mécanismes en détail".
 
Ça semble difficilement conciliable, surtout pour un framework de cette envergure.
 
Désolé si je t'ai froissé
 

 
Tu veux quoi qu'il arrive différents templates pour séparer correctement tes différents éléments. En fonction de certains événements, tu changeras le modèle sur le contrôleur.
 
Si tu as une partie de ton écran qui doit avoir un différent template en fonction du contexte, tu peux utiliser un outlet et connecter différents contenus selon tes besoins.

je ne connaissais pas

Ma question est assez spécifique: je ne *veux* pas.  
Je ne *veux* pas d'un fichier d'une seule ligne juste parce qu'un mec à l'autre bout du monde a décidé que c'était mieux pour mon projet. ça n'est pas mieux, parce ça va me forcer à multiplier mes fichiers d'une ligne, ça va m'obliger à commencer à les classer dans des répertoires, ça va obliger le compilo à faire des descentes récursives, ça va me faire chier à naviguer, ça va augmenter la relouterie dans github en ligne.
 
Ce template ne porte pas son poids, il doit être mergé avec autre chose. Je veux pouvoir moi-même décider de l'arrangement de mon code dans des fichiers.
Même si dans cet exemple précis, l'évolution du code me portait à le spliter dans un fichier propre pour des raisons qui me plaise, le cas se reproduit tous les jours, il est important de pouvoir choisir sa granularité, de ne pas se la faire imposer.
 
L'exemple classique est le type qui te force à séparer physiquement tes vues des contrôleurs "parce qu'il faut séparer proprement", sauf que si l'intégralité du bout qui utilise le framework est ridiculement petit par rapport au reste du projet, ou s'il ne touche qu'un domaine spécifique du business, alors foutre la vue et le contrôleur ensemble dans le même fichier parce que c'est les seuls qui touchent à ça peut avoir du sens, pour pas étaler un projet qui a déjà un problème de taille. Et on a bien séparé les choses, simplement on a coupé dans un axe différent que mécaniquement vue/contrôleur ou maître/détail.
 
Pour en revenir à cette séparation spécifique maître/détail, mettre une vue qui a connaissance du maître dans le détail est déjà une erreur philosophique de séparation des idées. Le maître a forcément connaissance des détails (puisqu'il est une agrégation de détails) mais les détails n'ont pas forcément connaissance de leur maître, donc forcer une vue qui connait le maître dans le template spécifique du détail, c'est rajouter un lien à l'envers dans qui a besoin de savoir quoi, puisque maintenant maitre et détail savent qui est le maitre, maintenant tout le monde sait afficher le maître et tout le monde sait afficher le détail. Alors qu'en séparant hiérarchiquement on peut laisser tout ce qui concerne le détail dans l'ignorance du maître, et on a brisé la boucle de dépendances.
 
Tu va me dire que le paté au-dessus est théorique et que dans la vraie vie on s'en fout des dépendances, sauf que tu m'as répondu sur un terrain théorique qu'il faut séparer correctement. Et dans ma vraie vie à moi, un truc important c'est la séparation par ordre d'idée "business" (ce qui concerne le calcul de trajectoire, ce qui concerne le calcul de vitesse d'outil, etc.), plus que de monter à des geeks que je sais séparer un maître d'un détail. Et un vrai truc important pour moi, c'est de découper mes fichiers comme je veux (enfin, autant que possible, parce que mettre un template dans du JS c'est pas gagné, et cet enculé de chrome veut pas de code dans les balises <script>, alors que les templates dans les <script> ça peut être un outil intéressant dans la toolbox). En général, j'essaye que mes fichiers fassent entre 30 et 300 lignes. Avant je viole les règles de séparations (m'enfin sur 30 lignes, ça devrait bien se passer la gestion du logiciel, hello util.js) et après 300 lignes j'essaye d'utiliser une excuse du monde de l'objet pour spliter une classe. Le nombre de fichiers et leur taille c'est le nerf de la guerre en développement.

 
Ça tombe bien ce n'est pas le cas avec Ember.

j'imagine que donner une URL aux résultats de mes long calculs et utiliser l'état loading du routeur pendant que ça calcule ça serait très très mal ?
 
Le vrai problème, c'est que ça prend pas en charge les résultats partiels ou le chargement progressif.

Le problème de cette approche, c'est que tu vas bloquer l'utilisation de l'application.
 
Je ne sais pas si c'est ce que tu veux vraiment en terme d'experience utilisateur.
 
C'est quoi l'ordre de grandeur de ces calculs ?
Tu ne les lances pas dans un web worker ?

sisi.  
J'ai pas vidé tout mon cerveau: le seul endroit où Ember supporte les promises c'est dans le routage (j'ai greppé le code source il y a quelques version). Donc le seul endroit où on peut avoir un peu d'aide c'est en mappant l'appel a worker comme si c'était un appel distant.

les calculs peuvent être longs:
http://nraynaud.github.io/webgcode/text.html
 
(enfin, si un jour je décoince mon cerveau, je vais utiliser une méthode plus rapide, mais pour ça il faut le diagramme de voronoi)

Tu peux utiliser des promises ailleurs.
 
Tu peux très bien créer ton worker, et gérer ça dans un controlleur a part. L'idée d'utiliser une route te permet de t'affranchir de prendre une décision sur ce que peut faire l'utilisateur pendant ce calcul.
 
Sinon, tu gères ça a part, et il faut implémenter un système de notification pour que l'utilisateur sache quand le calcul est fini  ( avec un lien ou un truc dans le genre pour qu'il puisse visualiser le résultat )

en fait c'est exactement ce que j'ai fait dans le lien que j'ai posté

Je suis a un mariage et sur mon téléphone

Visucam.Document = DS.Model.extend({
            operations: DS.hasMany('operation')
        });
 
        Visucam.Operation = DS.Model.extend({
            name: DS.attr('string'),
            outline: DS.attr('string'),
            toolpath: DS.attr()
        });
 
        var machine = new cam.Machine(null);
        var p1 = 'M0,0l100,0l0,25l-19.01440659255054,0l-25.02682544447841,-21l-11.917535925942104,0l-25.02682544447841,21l-19.01440659255054,0Z';
        var p2 = 'M0,0L0,60L35,60L35,45L20,30L35,15L35,-15L20,-30L35,-60L0,-60Z';
        Visucam.Operation.FIXTURES = [
            {
                id: 1,
                name: 'dremel bracket',
                outline: p1,
                toolpath: machine.fromClipper(machine.contourClipper(cam.pathDefToClipper(p1), 3, false))
            },
            {
                id: 2,
                name: 'V blocks',
                outline: p2,
                toolpath: machine.rampToolPathArray(machine.fromClipper(machine.contourClipper(cam.pathDefToClipper(p2), 3, false)), 0, -10, 5)
            }
        ];
        Visucam.Document.FIXTURES = [
            {
                id: 1,
                operations: [1, 2]
            }
        ];

bon, c'est légèrement attardé mental come API (tu sais pas faire une descente récursive, tu veux un bonbon ? t'as peur des boucles ? j'te donne 10centimes pour acheter un détecteur), on va bien trouver une fonction qui charge récursivement au lieu de shallow (j'ai un PB plus tard dans l'ui et l'async, il fait juste un écran blanc sans aucune erreur, il me faut une stacktrace pour trouver le pb).
 
30min de google ... pas trouvé de fonction de chargement récursif.
 
bon le moins pire semble être find() en ajoutant les trucs qu'on veut sideloader (déjà paye ton dry, il faut ré-écrire le contenu de la fixture dans l'appel).
 

this.store.find('document', 1, {operation: [1, 2]}).then(function (result) {
                    console.log('ApplicationRoute.model', result.get('operations'));
                });

bizarre, on dirait qu'il a pas fait le side-loading. Peut-être que c'est pas un nom d'entité, mais un nom de relation qu'il faut mettre:

this.store.find('document', 1, {operations: [1, 2]}).then(function (result) {
                    console.log('ApplicationRoute.model', result.get('operations'));
                });

oulà la soirée va être compliquée, t'es *obligé* d'avoir un nom d'entité=nom de la relation, et on voit bien qu'ils ont choisi un exemple du tonnerre dans la doc par rapport à ça.
 
 
Bref, j'en suis à démonter ember-data depuis plus d'une heure, alors que j'ai juste 2 fixtures avec une relation et que mon vrai problème c'est un template qui s'affiche pas.

'tain c'est l'horreur, j'ai des objets persos dans mon graphe de records et il détruit leurs prototype dans l'adaptateur, mais il semble pas appeler mon transformateur custom non plus quand j'essaye d'être un bon citoyen (sauf si j'ai fait une faute d'orthographe ou utilisé le nom du mauvais truc comme convention, mais je crois avoir bon).

edit: 'tain trouvé. c'est un nom de classe que j'ai foiré.

c'est quoi l'état de l'art du polymorphisme dans ember data ?
je vois des class_type pour la clef sur certains sites, des classType, des ClassType, et dans la doc je trouve rien ni aucun guide (enfin pas dans la recherche du site d'ember en tout cas)

Visucam.Document = DS.Model.extend({
            operations: DS.hasMany('operation')
        });
 
        Visucam.Operation = DS.Model.extend({
            name: DS.attr('string'),
            outline: DS.attr('string'),
            toolpath: DS.attr()
        });
 
        var machine = new cam.Machine(null);
        var p1 = 'M0,0l100,0l0,25l-19.01440659255054,0l-25.02682544447841,-21l-11.917535925942104,0l-25.02682544447841,21l-19.01440659255054,0Z';
        var p2 = 'M0,0L0,60L35,60L35,45L20,30L35,15L35,-15L20,-30L35,-60L0,-60Z';
        Visucam.Operation.FIXTURES = [
            {
                id: 1,
                name: 'dremel bracket',
                outline: p1,
                toolpath: machine.fromClipper(machine.contourClipper(cam.pathDefToClipper(p1), 3, false))
            },
            {
                id: 2,
                name: 'V blocks',
                outline: p2,
                toolpath: machine.rampToolPathArray(machine.fromClipper(machine.contourClipper(cam.pathDefToClipper(p2), 3, false)), 0, -10, 5)
            }
        ];
        Visucam.Document.FIXTURES = [
            {
                id: 1,
                operations: [1, 2]
            }
        ];

this.store.find('document', 1, {operation: [1, 2]}).then(function (result) {
                    console.log('ApplicationRoute.model', result.get('operations'));
                });

this.store.find('document', 1, {operations: [1, 2]}).then(function (result) {
                    console.log('ApplicationRoute.model', result.get('operations'));
                });

 
Je déconseille le FixtureAdapter.
 
J'utilise sinon.js, pas encore regarder pretender.

Pour la doc, ça fait des mois que je me dis qu'il faudrait que je fasse une PR pour clarifier le nommage. Le choix de nom de classe avec un seul mot, ne permet effectivement pas de savoir quoi utiliser selon les besoins.

ben moi pour l'instant je ferai bien tout JSON en dur dans mon code. A plus long terme ça va se retrouver en localstorage qui est aussi une API synchrone (ou asynchrone mais super rapide dans l'app google).
 
 
là c'est chaud sur le polymorphisme, j'ai ça:

Visucam.Operation = DS.Model.extend({
            name: DS.attr('string'),
            outline: DS.belongsTo('shape'),
            inside: DS.attr('boolean'),
            toolDiameter: DS.attr('number'),
            toolpath: DS.attr('toolpath')
        });
        Visucam.RampingContourOperation = Visucam.Operation.extend({
            rampZ: DS.attr('number')
        });
        Visucam.SimpleContourOperation = Visucam.Operation.extend({
            startZ: DS.attr('number'),
            stopZ: DS.attr('number'),
            turns: DS.attr('number')
        });
 
        Visucam.Document = DS.Model.extend({
            operations: DS.hasMany(Visucam.Operation, {polymorphic: true}),
            shapes: DS.hasMany('shape')
        });

comment je peux écrire une fixture pour les opérations ?
 
j'ai tenté ça, mais il a pas l'air d'aimer:

Visucam.Operation.FIXTURES = [
            {id: 1,
                name: 'outer profiling',
                outline: 1,
                toolDiameter: 3,
                inside: false,
                type: 'Visucam.RampingContourOperation',
                toolpath: {className: tp1.getTypeName(), path: tp1.path}
            },
            {
                id: 2,
                name: 'inner profiling',
                outline: 2,
                toolDiameter: 3,
                inside: true,
                type: 'Visucam.SimpleContourOperation',
                toolpath: {className: tp2.getTypeName(), path: tp2.path}
            }
        ];
        Visucam.Document.FIXTURES = [
            {
                id: 1,
                operations: [1,2
 
                ],
                shapes: [1, 2]
            }
        ];