Reprise du message précédent :
Tu peux très bien distribuer ton composant dans un fichier en l'attachant au scope global (comme jQuery par défaut), libre à l'utilisateur ensuite de l'attacher lui même au namespace de son appli.
 
 
Mais la véritable réponse à ce problème va être l'utilisation d'un module ES6. Chose que tu peux faire aujourd'hui en utilisant Ember App Kit, et très bientôt de base quand la conversion du code d'Ember sera finie.

Est-ce que je peux remplacer mon framework cakephp par EmberJs pour développer une appli ou bien est-ce que ça reste qu'un complément ?

Tu ne veux probablement remplacer que la partie View de cakephp. Ember.js est un framework JavaScript qui s'exécute dans le navigateur, il y a de fortes chances que tu veuilles encore un serveur pour gérer au moins la persistance des tes données (même s'il y des cas ou ce n'est pas vrai)

Je demandais juste au cas ou car il me semblait avoir vu vite fait un truc avec emberjs data mais pas creusé plus  

C'est le sens de mon "même s'il y des cas ou ce n'est pas vrai".

Tu peux utiliser le local storage, une API externe, un service comme firebase pour stocker tes données. Je ne sais pas ce que fait ton appli aujourd'hui.

Je n'ai pas encore lu entièrement, mais ca promet d'être intéressant.

https://twitter.com/BenLesh/status/461735615592022016

les .get('property') et .set('prop', value), c'est pour la compatibilité avec les browsers qui n'ont pas les properties custom ?
si je cible pas les navigateurs à la con, je peux accéder normalement aux propriétés ?

 
Oui, pour les navigateurs ne supportant pas `Object.defineProperty` si je ne m'abuse.
 
http://kangax.github.io/es5-compat-table/
 

 
Je ne sais plus, à tester.
 

trouvé,
http://jfire.io/blog/2012/04/19/wh [...] scriptors/

Vu la date de l'article, je ne me satisferais pas de ça. Comme dit précédemment, tous les articles pré-v1 n'ont souvent pas grande valeur.

Mais il y a moyen que cette réponse soit encore valide

le problème c'est que si je me repose sur le fait que ça marche aujourd'hui sans avoir d'assurance un peu politique que ça marchera demain, je me fous dans un piège.
Parce qu'ils hésitent pas à casser les trucs qu'ils aiment pas, genre AMD.

L'API ne changera pas avant la version 2.0, je ne sais pas de quoi tu as concrètement peur ou quel est le problème avec les modules AMD.

Je suis a 2 doigts de faire adopter Ember a ma team au boulot, ils voulaient commencer a utiliser Angular
 
On va faire quelques essais en recreant un ou 2 modules existant sous Ember voir si ca fonctionne bien
 
J'espere que je vais pas regretter ou je t'insulterais en secret

Faut pas hésiter à poser des questions surtout
 
Ou à me faire venir pour aider à lancer le projet, j'ai des dispos en Mai

le getters directs je les trouve pas dans l'api

 
Non mais je ne pense pas que ca marche aujourd'hui. Donc tu ne risques pas de les utiliser  

clairement, il y en a aujourd'hui.

on dirait qu'il les créé à la volée quand on ajoute des listeners, ce qui semble intelligent.

Je ne pense pas.
 
http://emberjs.jsbin.com/boyot/1
 
Si tu tapes dans la console Chrome
 

 
Alors que `myValue` est utilisé dans le template.

je viens de découvrir ça: http://emberjs.com/api/classes/Ember.Evented.html
ça peut être pas mal pour les cas où on veut pas foutre ses dépendances en vrac ou faire des vraies properties.

Ember App Kit est deprecated, place à Ember CLI, qui utilise broccoli comme build library.
 
http://www.ember-cli.com/

Un site recensant des sites utilisant Ember.js
 
http://builtwithember.io/

L'extension pour débugguer les applications Ember est dispo pour Firefox  
 
https://addons.mozilla.org/en-US/fi [...] inspector/

Pour une appli qui doit être en mesure de recevoir des updates du serveur, je pars sur Socket.IO ou il existe un truc spécifique ou adapté à Ember ?
A part cette réponse SO, j'ai pas trouvé grand chose sur le sujet.

C'est l'approche la plus simple à mettre en place.
 
Tu crées un initializer qui va enregistrer dans le container ton socket socket.io. Un autre initializer va faire le lien entre  l'évènement sur ton socket et le store.

n'hésite pas à demander des précisions si ce n'est pas clair.

Avec plaisir ! Pour le moment, je regarde la faisabilité pour la prochaine appli, mais les questions plus spécifiques risquent d'arriver très vite.

 
Normal pour du WIP, mais pour le moment c'est inutilisable sous Windows. J'ai recommencé 4 fois les différentes install avant de pouvoir produire le squelette de base, qui génère une erreur au déploiement.
Voir https://github.com/stefanpenner/ember-cli/issues/1558 notamment, à suivre.

Puisque c'était si gentiment proposé
 
Je suis sur le Getting Started et je m'interroge sur le pourquoi de la multiplication des controllers.
 
Step Creating a New Model Instance, on déclare un controller sur Todos avec une fonction createTodo. Sur un Adapter REST(-like), j'apparenterais ça à un POST sur /todos.
Step suivant Mark Model as Complete or Incomplete, on créé un nouveau controller sur Todo, alors que la méthode vise le même type de ressource (en read/update).
 
Il y a une raison particulière ? Est-ce que ma confusion vient du fait que le concept de route est plus proche de ce que j'évoque que le controller ?

La réponse courte est :  je ne sais pas la véritable explication
 
La réponse un peu plus longue avec mon idée sur la question : les controllers peuvent être vus comme des singletons qui ne sont pas recréés en changeant de route. Ember créer un controlleur par route et n'a pas vraiment de moyen de deviner si ce controlleur représente vraiment le même model, et bien il en crée un nouveau d'un autre type.
 
Il s'agit du comportement par défaut, que tu peux changer, en utilisant l'attribut `controllerName` sur une route ( http://emberjs.com/guides/routing/ [...] ontroller/ ), ce qui te permettra de réutiliser un controller entre plusieurs routes.

OK, je commence à comprendre.

Ma première confusion : ici (Ember vs mon intuition), le controller a un état. L'exemple de l'ordre de tri sur une table me parait pas mal pour comprendre le pourquoi.
Deuzio, Ember créé un controller par route.
Tertio (et c'est là où je suis moins sûr), les routes /foos et /foos/1 sont différentes, d'où la création de controllers distincts pour un même type de resources.

J'ai bon ?

 
Ce que je voulais dire, c'est qu'Ember créé une classe (extends()) de controller par route.
Pour les instances (create()) tu m'as un peu perdu, mais ta réponse ne va pas à l'encontre de celle de Youmoussa ? Comment il conserve l'état dans ton cas si une nouvelle instance est créée à chaque requête ?
 

laisse tomber, j'ai dit n'importe quoi.

 
Si j'ai bien compris ce que tu dis, oui

Un point en particulier sur lequel j'ai été flou ?
C'est le tertio qui m'embête - même si ta solution permet de passer outre - je trouve qu'un seul controller dans ce cas aurait été plus logique (1 controller = 1 ressource).

c'était plus le "le controller a un état" qui me rendait incertain. Mais l'exemple associé est bon

Par contre dire que /foos et /foos/1 utilisent la même ressource, c'est faux. /foos utilisent probablement une liste d'objects, /foos/1 plutôt un objet ( distinction entre ArrayController et ObjectController ).

J'étais pas clair effectivement, je pensais au même type de ressources.
Je pense que je fais trop l'amalgame entre ce que j'attends du controller Ember et ce que je vois/fais généralement sur les controllers REST côté serveur.

L'analogie avec une appli Rails/Django peut aider mais a également ses limites.
 
Si tu as une page web avec 2 parties, une liste d'objects à gauche, un espace pour visualiser des propriétés d'un objet sur la droite.
 
La liste sera gérée par le controlleur de /foos alors que la partie droite sera gérée par le controlleur de /foos/1. Les 2 existent simultanément et ne représentent pas la même donnée ( même si le type des objets est le même )

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