Unfinished. All the points you raise are invalid. Tom and Yehuda are working very hard on ember itself. A RC is finally around the corner. Ember data will get the same treatment. It will take time. Ember data is more ambitious and complicated then ember.
I'm facing a similar situation, and my big question is: What's the alternative? Do I just roll my own REST layer on top of basic Ember objects or has someone figured out a working alternative?
ember-rest and ember-resource are two much simpler alternatives.
However, neither has the ambition or potential power of ember-data. Transactions are becoming better defined, it's possible to attach a model to a transaction much like you said and to commit that transaction independently of any default transaction.
Ever other library I've looked at for this, and the roll-your-own solution would require that you implement hacks like cloning an existing model before editing, and won't actually gain you much.
Another thing to consider, while the adapter is called the RESTAdapter, it is tightly coupled with a particular way of using Rails models. And unfortunately, at least when I was considering this approach, replacing it gets you back to the "roll-your-own" solution, so much of the state management logic was actually in the RESTAdapter that using a different way to pack multiple models required reimplementing it.
It would be nice if the store would support an API that can update a model offline, or create a savable copy in a transaction, or handle a type of master-master synchronization when connection was restored.
It has definately improved and the vision seems to be getting more concrete.
Certainly unfinished. Unlike Ember, Data hasn't had any releases. There's a reason for this. We don't think it's stable enough to recommend to anyone unwilling to do some hacking.
For sure. To that end, I spend a lot of time reviewing issues and contributing as best I can. From what I've seen, though, I'm not sure if it's even capable of being finished in a way that makes sense.
I'm pretty confident in Yehuda and Tom's ability to figure things out. It's a very difficult problem to solve, as evidenced by the slow pace of progress, but I think it is a solvable one.
If Ember-Data isn't ready for production, and Ember is, then why is it in the documentation on http://emberjs.com? Either it's ready to be used, and can go in the official guides, or it isn't, and the guides should recommend something that is ready to use.
That's my feeling too - I've gotten a number of responses to the effect of "well, there hasn't been a release" but the official line at conferences, talks, and in the documentation is "this is the way to use Ember" so I think that's a distinction without a difference.
8 comments
[ 1.5 ms ] story [ 28.4 ms ] threadHowever, neither has the ambition or potential power of ember-data. Transactions are becoming better defined, it's possible to attach a model to a transaction much like you said and to commit that transaction independently of any default transaction.
Ever other library I've looked at for this, and the roll-your-own solution would require that you implement hacks like cloning an existing model before editing, and won't actually gain you much.
Another thing to consider, while the adapter is called the RESTAdapter, it is tightly coupled with a particular way of using Rails models. And unfortunately, at least when I was considering this approach, replacing it gets you back to the "roll-your-own" solution, so much of the state management logic was actually in the RESTAdapter that using a different way to pack multiple models required reimplementing it.
It would be nice if the store would support an API that can update a model offline, or create a savable copy in a transaction, or handle a type of master-master synchronization when connection was restored. It has definately improved and the vision seems to be getting more concrete.