Our experience with Ember
labs.kollegorna.seWhile we're on the subject of Ember, can an ember guru please share some of your wisdom by explaining the following:
Q1: When given some instance of DS.Model, how does DS.Store figure out what child-class of DS.Model it is?
Q2: Where and how do DS.Model child-classes get registered with the main ember application?
Q3: Say you have some model Person = DS.Model.extend(...) and some PersonAdapter = DS.ActiveModelAdapter.extend(...), when does Ember go about and register your PersonAdapter and figuring out it should be used with the Person model?
I'm trying to create something very like the DS.Adapter system for Ember, except instead of handling ajax requests for data persistence, it would do data live updates, but I'm confused at exactly how Ember goes about registering its parts.
Hi, I will try to answer your questions:
It is all about the resolver who does this job for you.
Ember convention is to have adapter & serializer per model which comes abs brilliant when you go into later stage in your project. If you intent to have model Person Ember would expect that you provide Person(Model) , PersonSerializer ,PersonAdapter where missing will use the application default ones. Default ones are resolved with App.ApplicationAdapter, App.ApplicationSerializer .
So if you do store.find('person', 1) Ember's default resolver would try App.Person then resolve the adapter App.PersonAdapter || App.ApplicationAdapter and App.PersonSerializer || App.ApplicationSerializer.
1) Store will use the resolver to identify the class
var attr = DS.attr;
App.Person = DS.Model.extend({ firstName: attr(), lastName: attr(), birthday: attr() });
store.find('person', 1);// resolver will search in App.Person (classified name) namespace (ember-cli will do that a bit differently)
2) the application namespace where the resolver performs the lookup - check App.__container__ registry
3)That's how the resolver work it checked as stated above.
Hope this helps you.
Yes, it does help. You have set me on the right track and I will now look into the Ember.Resolver. Thank you.
Another thing: Ember-Data doesn't support PATCH (last I looked) so it requires sending the whole model to save changes. This can have unintended consequences when you only want to update one thing, but have to send everything.
This is very different at the moment, not only you could have patch updates for the modified properties but you could also perform rollback in case something is rejected by the server and so on and on.
It's always helpful to see summaries of other people's experiences with platforms. Ember is going through a big growing period right now and feels like a moving target, but it has a strong direction.
Note that ArrayControllers (which are often/always used as part of an "each" loop, and can set via itemController in handlebars, if needed) are not singletons, unlike standard controllers. Very useful for lists of items that need individual control.
"Controllers are singletons" is something i really like in Ember. Why should I execute all the code every time a view loads..