> Epf is essentially an ORM for the web and gives you all the tools necessary to define models and synchronize with your backend.
That line should be on the front page of that website. I've spent too much time trying to decipher the bizarre diagram and trying to figure out whether it was an inside joke I wasn't getting or an actual thing.
Sorry about the obtuse diagram. In my little Ember.js bubble it seemed important to differentiate it from things like Ember Data. These pages will improve.
Don't want to show off, but it seemed quite readable to me, once you notice that the arrows have numbers..
It shows many interesting details (the only API command seems to be Patch. There are two sync phases on the client, one to determine what to send to the server, one to determine what to merge upon server response). I quite like diagrams :))
I'm assuming - and this could be a bad assumption - but based on the continuing updates architecture, if client a changes model a, client b will see an update on model a. How does client b get notified of the change? Does it have some kind of fallback system ala socket.io? Is this not yet part of the project?
Judging by the chart on the site, it looks like each client polls the original model on the server, and infers changes by diffing it against the client's current copy.
It tries to be agnostic about this and favor any particular push method. Instead, it simply provides the primitives on the client to make these things easy (e.g. merging in new data).
Author of Epf here. We had used Ember data for over a year before creating and switching to Epf.
Epf was heavily inspired (if not directly based on) many parts of Ember Data. We felt that Ember Data provided the right level of abstraction, but fell short and created road blocks for us in certain scenarios.
I've been using Ember-data for the past few months on side projects and it's getting a lot more stable. I've rarely had issues with it in the past few weeks.
"weeks" ??
Damn... I remember when I had to choose between angularJs and other JS frameworks a few months ago. Reading your comment makes me feel really good with my choice.
I've played around with Angular quite a bit lately as well and I definitely prefer Ember. You should really try both of them out and give them both a fair chance.
Also, you don't have to use data with Ember, it's just a benefit.
Last time I used it, I think it was Revision 11, it had issues with relationships and deletions, how is it holding up now? I'd love to give it another go!
There are still issues on rev13. For example, when binding to the didCreate event after committing a model, the model.id is not defined. You would think `didCreate`, fired when a response is returned from the server, and that response includes the complete model including the ID, your client-side model would now include the ID as well. Not so! You have to do tricks like `model.addObserver('id')` to get what you need.
Ember.js is great fun, until it goes horribly wrong. On the other hand, the Ember Core team does not call it a 1.0 — and they certainly do not say Ember Data is finished. I think it's unfair to judge such early builds.
Is this supposed to be a framework for collaborative editing and synchronization? I would expect a lot more examples around merge conflicts and locking if so. "Models are never locked" make this sound like it is just an abstraction for abstraction's sake, why would I use this instead of just binding DOM elements to JSON?
It's made to be a generic ODM/ORM for use on the client side with Ember.js. It's a replacement for Ember Data, which has a ton of bugs and limitations.
That line should be on the front page of that website. I've spent too much time trying to decipher the bizarre diagram and trying to figure out whether it was an inside joke I wasn't getting or an actual thing.