Reprise du message précédent :
Pour le moment je n'ai fait que du maquettage basique à base de FixtureAdapter, mais tu vas peut-être pouvoir m'éclairer sur une zone floue.
L'idée est bien évidemment d'utiliser un RESTAdapter, mais j'ai l'impression qu'à ce moment, je serais obliger de dédoubler ma logique métier. J'imagine que la synchro entre le modèle client et le serveur se fait au moment du model.save() et je ne vois donc pas comment faire autrement que contrôler mes données deux fois, de chaque côté.
 
On va prendre un exemple parce que j'ai l'impression que je suis pas clair et disclaimer, c'est mon premier FW JS, on faisait tout à la mano avant. On imagine une transaction de 3 patates entre A et B. Il faut que A ait assez de patates dans son sac et que B ait assez de place libre dans le sien. Ces contrôles là, je vais les réaliser côté client, dans Ember, puis sauver les modèles A et B lorsque j'aurais la garantie que les conditions sont réunies. J'intuite qu'à ce moment, le modèle va se synchroniser avec le distant, et donc envoyer deux updates sur les stocks courants de A et B. Si je veux être certain de l'intégrité de mes données, il faut que lors de ces updates je rejoue côté serveur les contrôles effectués côté client.
 
Si c'est le cas ça m'amène une seconde interrogation. Si côté serveur, et malgré des contrôles positifs côté client, j'ai un rejet des transactions (logique métier différente des deux côté par erreur, race condition ou tout simplement une 500), le modèle client est-il rollbacké à son état d'origine ?
 
Je suis à côté de la plaque ? J'ai lu à propos de model.commit(), mais ça n'a plus l'air supporté pour ember-data 1.0.0 beta. En utilisant Promise, model.save().then() ? Si oui, la doc est pas très claire sur ce qui est rollbacké, les champs concernés doivent être resetées manuellement dans le callback fail ?
 
Finalement ça se résume à deux questions : la logique métier est-elle dédoublée entre client/serveur, et la transaction fait-elle bien appel à model.save().then() ?
 
Merci et désolé pour le pâté confus, on est en soirée ici et j'écluse mes questions de la journée avant d'aller au pieu

Pour faire simple, n'utilise pas le FixtureAdapter.
 
Il vaut mieux utiliser le REST Adapter avec une librairie comme sinon.js.

Je ne connais pas ton architecture, mais je vais partir du principe que tu as effectivement besoin de mettre a jour 2 ressources.
 
 
Oui, en fonction de ton besoin, tu peux être amené à dupliquer certaines règles. Ce n'est pas obligatoire, tu peux laisser la sauvegarde échouée et ne traiter que l'erreur côté client. Ça dépend de quelle UI/UX tu veux.
 
 
Pour la sortie d'erreur avec Ember Data, il ne me semble pas que ce soit automatique. Tu vas devoir gérer manuellement. Tu dois pouvoir utiliser record.rollback.
 
ember data est a nouveau en transition, je ne sais pas ce qui marche ou pas actuellement à ce sujet.

Twitch, qui vient de se faire acheter 1 milliard de $$ par Amazon, utilise Ember.js

http://emberjs.com/guides/template [...] -template/
question à la con, cet application template il est rendu comme une vue ?
(mentez pas, il a la classe CSS ember-view)
Comment je peux choisir la classe qu'il va instancier ?
 
En fait techniquement j'ai juste envie d'ajouter une classe CSS dessus, mais savoir comment la choisir peut être utile pour plus tard.

j'me réponds:
http://stackoverflow.com/a/11400596/72637
il va chercher une Classe nommée "ApplicationView".
 
(marrant, c'est un pote de Besançon qui a répondu.)

Un template a toujours une vue pour le gérer.  
 
Ember en crée une par défaut s'il n'existe pas une avec la bonne convention de nommage.

vous arrivez à configurer le file watcher de jetbrains pour lancer ember-precompile ?
j'arrive pas à faire globber le truc, et je trouve pas d'argument pour dire à l'exécutable de prendre tout ce qu'il y a dans le répertoire.
actuellement j'utilise

mais ce con d'intellij globbe pas (et j'ai pas trop envie d'ajouter une script dans le projet)

Je n'utilise pas jetbrains personnellement.

En général, tu lances `ember serve`, tu modifies les fichiers dans ton éditeur et quand tu sauvegardes, c'est automatiquement géré par ember-cli/appkit.

Ca ne fonctionne pas pour toi ou c'est différent de ce que j'explique ?

non j'essayais d'avoir un plugin dans l'IDE, un truc de moins à oublier, du coup pour l'instant j'ai comité un .sh.
mais ça devient le bordel avec le C, le ember, la compression JS.

 
T'as configuré le bon File Type ? Y'a pas une histoire de templates/**/*.handlebars ? T'as défini un scope custom sur ton watcher ?

nan, mais le watcher il voit que un fichier a changé mais moi je veux tous les recompiler d'un coup à chaque fois quand un d'entre eux change, d'où le globing. Mais dans les petites variables qu'il propose pour construire les arguments, il peut y avoir le fichier individuel qui a changé, mais pas la liste de tous les fichiers du répertoire. le wilcard marche pas, j'ai vu une mention de ça dans la doc.

 
Je n'ai pas compris ce que tu peux oublier en fait. Tu ne veux pas lancée 'ember serve' quand tu développes ?
 
C'est parce que tu packages l'application après ?

ouais, je voudrais éviter d'avoir à lancer un truc avant de développer (à la main quoi l'IDE peut le faire, en gros ça va me saouler d'oublier, l'IDE on peut pas oublier de le lancer).
 
L'appli est pas encore vraiment pacakgée, pour l'instant je dois compiler le C et compiler les templates ember (eval() interdit dans l'env google).
J'ai commencé à écrire la config pour la minimisation avec require.js parce qu'il commence à y avoir *beaucoup* de fichiers ( http://nraynaud.github.io/webgcode/webapp/CAM.html y'en a une partie là, mais ça c'est ouvert dans une iframe et y'a le contrôleur au-dessus )

 
Peut-être regarder au niveau de la conf / du source du watcher SASS par exemple, y'a le même besoin de recompilation globale en cas de changement unitaire.

 
   
 
Du coup ce que produit Ember-cli ne peut pas être utilisé dans une extension ? Bon à savoir.
 
Bon je commence ma journée de taf ( et je ne connais pas bien broccoli et le building process pour le moment ), mais je jèterai un œil ce soir si j'oublie pas.
 
Mon réflexe serait de jeter un œil a ce que faisait le watcher d'Ember App Kit.

de base y'a pas grand'chose qui marche dans une app google chrome

putain, mais j'y capte rien à quelle convention de nomage doit appeler quoi ça fait 30 min que j'essaye d'afficher une liste, dans le tuto tout s'appelle "Todos" du coup on sait pas ce qui est de la convention de recherche et ce qui est simplement ce que les devs ont décidé.

"use strict";
require(['Ember', 'EmberData', 'templates'], function (Ember, DS, templates) {
    Ember.TEMPLATES['application'] = Ember.TEMPLATES['visucamApp'];
    
    window.Visucam = Ember.Application.create({});
 
    Visucam.ApplicationAdapter = DS.FixtureAdapter.extend();
 
    Visucam.Router.map(function () {
        this.resource('operations', { path: '/' });
    });
 
    Visucam.OperationsRoute = Ember.Route.extend({
        model: function () {
            return this.store.find('operation');
        }
    });
 
    Visucam.Operation = DS.Model.extend({
        name: DS.attr('string')
    });
 
    Visucam.Operation.FIXTURES = [
        {
            id: 1,
            name: 'Learn Ember.js'
        },
        {
            id: 2,
            name: '...'
        },
        {
            id: 3,
            name: 'Profit!'
        }
    ];
});

le template "visucamApp" (enfin "application" du coup)

le HTML est juste un <body></body>

et le DOM généré est :

<body class="ember-application">
 
 
<div data-label="layer-div" style="display: none;"></div><div data-label="preview-div" style="pointer-events: none; display: none;"></div><div id="ember442" class="ember-view"><div class="operations">
    <ol>
        <script id="metamorph-0-start" type="text/x-placeholder"></script><script id="metamorph-0-end" type="text/x-placeholder"></script>
    </ol>
</div></div></body>

la route en gras dans l'inspecteur est "operations", dans les data y'a mes 3 trucs. Je sais pas quoi faire.

Cette fois-ci je pense jouer avec les routes à la con si un jouer j'arrive à les comprendre, parce que je suis dans un modèle un peu plus classique avec un graphe d'entités, pas très loin du todo.

{{#each}} au lieu de {{#each operations}}

Ta route retourne un tableau d'opérations ( la méthode 'model' de la route).
 
Ember va ensuite prendre ce tableau et l'affecter au controlleur de cette route ( la méthode 'setupController'  de la route)
 
Ensuite le template est associé à une vue et un controlleur ( méthode 'renderTemplate' de la route ).
 
La conséquence de tout ça, est que le this/contexte de ton template est le controlleur, qui est lui même un proxy de ton tableau d'opérations.
 
Donc quand tu écris {{#each operations}} Ember s'attend a trouver une propriété operations sur ton controlleur ou ton tableau d'opérations.
 
En utilisant simplement {{#each}}, il considère que le contexte/this est un enumerable, ce qui est le cas puisqu'il s'agit de ton tableau à travers le proxy.

merci pour ton aide.

avec {{#each}} ça me donne 2 erreurs dans la console:

dans la situation précédente, en comparant les debuggers ember (entre le tuto todo et chez moi), dans le premier onglet "View Tree", la colonne "Model" est vide (le reste semble cohérent), ce qui fait penser qu'il a pas été lire mon "OperationsRoute".  pourtant dans l'onglet "routes" la route "operations" est en gras.

http://imgur.com/a/mDPOR

Je suis en transport de retour vers chez moi, ça va couper un peu.
 
J'ai l'impression que ton controlleur n'étend pas ArrayController.
 
Une fois chez moi, je te montre comment vérifier ça.

c'est un controlleur par défaut du coup, j'en ai pas écrit.

Yep, j'ai vu. Quand tu ne déclares pas le controlleur ( en suivant la règle de nommage ), Ember va en créer un par défaut.
 
Normalement, il est assez intelligent pour détecter que ton model est un tableau et instancier un ArrayController
 
https://github.com/emberjs/ember.js [...] js#L26-L35
 
Je vais créer un JsBin pour voir ce qui cloche

la config:  
        Ember: "libs/ember-1.5.0-beta5.pre7",
        EmberData: "libs/ember-data-1.0.0-beta7",
(si ça doit tourner en vrai dépannage)

Rien qu'en copiant/collant ton code, ca m'a sauté aux yeux.
 
Tu avais vu juste, c'est bien un problème de nommage.
 
Ton template correspond à visucamOperations ( ou `operations` ) et pas visucamApp.

Regarde le JsBin
 
http://emberjs.jsbin.com/nolojo/1/edit

Le pourquoi du comment:
 
Ember commence par rechercher l'application. ( ApplicationRoute, ApplicationController, `application` template ). Il assemble toutes les pièces et effectue le rendu pour cette route. Ca ne correspond pas à '/', ca vient avant tout.
 
Ensuite il effectue de meme pour les sous routes, une à la fois, en suivant la hierarchie définie dans le routeur.
 
Dans ton cas, c'est simple, il n'y a qu'une route. Donc le but est de faire pareil qu'application, mais pour operations ( model de la route, creation/utilisation du controlleur, rendu du template..).
 
Comment les 2 routes s'emboitent ?
 
Il y a besoin d'un outlet ( sans nom par défaut ) dans le template parent pour y insérer le HTML généré par la route fille.
 
Donc, il te faut un application template qui contienne un outlet.
 
Si tu ne veux pas le créer, Ember le fera pour toi, sinon tu le définis, met ce que tu veux dedans et il ne faut pas oublier l'outlet ( tu n'aurais que le contenu de l'application template d'insérer dans le DOM, aucun message d'erreur il me semble )
 
 
Quel était ton problème ?
 
Ton application template s'attendait à avoir un tableau comme controller/modèle. Tu n'avais légitimement rien défini, donc Ember a créé un simple controlleur. Avec rien dedans ( puisque tu n'as légitiement pas défini l'ApplicationRoute et sa méthode model ).
 
Donc pour ton premier problème, Ember a cherché une propriété `operations` sur ApplicationController. Elle était nulle, et aucun élément DOM n'a été créé.
 
 
Le 2è problème vient du fait que, comme je l'avais expliqué, cette fois le #each cherche à itérer sur le controlleur directement. Celui ci existe ( pas null ), mais n'est pas un tableau ( ou proxy d'un tableau ). D'où le message d'erreur.

ok je regarde, je comprends la théorie, mais chez moi ça marche pas.  
 
J'ai renommé le truc en haut en "operations", visuellement j'ai toujours ma liste vide, mais dans le debugger Ember, j'ai bien un controlleur avec des données dans le modèle maintenant, on progresse. Je vais pétouiller un peu plus la différence entre chez moi et le jsbin.
 
('tain une heure, 2 personnes pour afficher 3 lignes dans une liste )

ah putain c'est bon, c'est le each chez moi j'avais remis le symbole.

Merci.  
 
'tain 'faut garder tout le modèle en mémoire, t'as aucune aide dans l'environnement
Je sais pas comment je vais faire, entre le fonctionnement interne de Ember, les vitesses de coupe, les états de mon contrôleur CNC, les timings des moteurs pas à pas, les calculs de trajectoires d'outils (et là niveaux maths c'est l'horreur), je peux pas tout retenir, il faut que ce soit affiché quelque part.
 
Je me souviens que dans swing ça allait, un click et on pouvais lire le code du framework. Peut-être que j'étais plus jeune et j'absorbais mieux.
 
En tout cas merci, c'est pas gagné cette appli

Faut que je regarde s'il y a moyen d'avoir un message d'erreur plus parlant dans le 2è cas.

Il y a clairement un manque sur comment assembler les pièces ensemble.

La documentation est assez bonne quand on prend les parties individuellement, mais ce n'est pas suffisant.

Mais bon, une fois que cette partie est comprise, on commence à pouvoir faire des trucs

je viens de mater ember-cli, je pense qu'il y en a pour facile 3jours rien que pour démerder qui fait quoi dans la liste des outils au nom à la con dans les trucs installés.
du coup, y'a peut-être moyen de l'utiliser pour faire des app chrome, mais il va falloir de l'aspirine. Je le vire, j'ai la flemme là tout de suite de me faire chier avec 10000 docs de plus.
 
Je voulais faire une petite app pour communiquer avec mon oscillo, mais je crois que je vais utiliser ember à la main, comme avant, au moins la complexification sera progressive et besoin par besoin. J'ai déjà 4 PDFs d'ouvert pour mon domaine d'application.

Ben c'est plus simple d'utiliser Ember-cli pour générer une appli Ember. Ca évite de réfléchir a toutes les étapes pour générer les fichiers a distribuer.
 
Tu fous tes classes/templates dans le bon répertoire et avec le bon nom de fichier pour suivre la convention, et tu fais l'import/export ES6, hop, ca marche.
 
App.MyObjectRoute -> app/routes/my-object.js
App.MyObjectController -> app/controllers/my-object.js
App.MyObjectView -> app/views/my-object.js
 
Par contre il me semblait que ça gênererait des fichiers à base d'"eval"
 
Le plus chiant est si tu as besoin d'intégrer des librairies js exotiques. Je ne sais pas si ça marche simplement pour le moment.

ça fait de l'eval, ça a des script inline dans le index.html, quand tu compiles, ça renomme les fichiers, et du coup il faut aller trouver l'outil qui fait ça, trouver sa doc, trouver son format, lui faire bouffer le manifest.json pour qu'il aille renommer le background.js renommé dedans etc. bref y'en a pour 3h de google pour faire un hello world.

 
 
Donc c'est bien sauf si on veut faire un truc pour une extension Chrome

 
Clair Certainement ce qui m'a le plus poussé à la faute pour le moment. Changer le nom de l'applis rendrait le tout nettement plus compréhensible.
 

 
Ça et l'utiliser sous Windows derrière un proxytaff.
 

 
Ben c'est un peu le principe de déclarer une ressource, tous les composants dérivent leur nom de cette ressource.
 
C'est ce que présente cette page de la documentation
 
http://emberjs.com/guides/concepts/naming-conventions/
 
Ça m'intéresse de savoir ce qui n'est pas clair.

L'application s'appelle Todos

 
Plus loin, on y ajoute une route

qui ne fait pas référence à l'application mais à la liste des ressources todo.
Bonus point : cette nouvelle route match le template 'todos' qui un peu avant cette étape, était associé au root path via  
 

Todos.Router.map(function() {
  this.resource('todos', { path: '/' });
});

 
Alors OK, à terme tu fais le distinguo entre routeur / route et les templates qui en découlent, mais au moment du tuto c'est IMHO la confusion totale entre les concepts, le routage par défaut de l'application et la route nouvellement déclarée.

Il y a effectivement le nom de l'application qui pourrait laisser porter a confusion.
 
Tu avais lu la page sur le nommage avant de regarder le tutoriel ?

 
Non
Getting Started, et ensuite je creuse.