Ember-Graph - An Ember-Data alternative

41

What is bad with this approach is that you need to implement each time the serialize, deserialize and isEqual logic, which is not needed.

Sometimes there are good reason to not have an entity. Yu could think of a “City” embeddable object. If you already have a “Address” entity (that is persisted), you may want to split the “City” concept into its own object (to have “name” and “zipCode” for instance), while still persisting it ALONG the address (in the same table).

A city is not an “attribute”. I’d like to be able to do that:

App.Address = EG.Model.extend({
   country: EG.attr(),
   city: EG.embeds('city')
})

App.City = EG.Embeddable.extend({
    name: EG.attr(),
    zipCode: EG.attr()
})

It expects this payload:

{“id”: 456, “country”: “France”, “city”: {“name”: “Le Perreux Sur Marne”, “zipCode”: “94130”}}

Of course, I suspect the “EG.Embeddable” to somewhat extends EG.Model, but obviously as it is not persisted, it cannot be fetched, removed, does not have identity map… so the only thing needed is tracking dirtiness, proper serialization with normalization…

Hope it makes sense :slight_smile:

42

If you want, I can write some issues tonight with more details about the Embeddable thing, and nested URL, I’d be glad to throw some thoughts about it :).

43

Yeah, feel free to put any feature requests or proposals on Github and I’ll take a look at them.

44

I think you are talking about value objects. While they are obviously not persisted on their own in a database, they shouldn’t be forced into the JSON schema of the payload either. The address payload should look like this: {"id": 456, "country": "France", "cityName": "Le Perreux Sur Marne", "zipCode": "94130"}.

The place of combining one or more attributes into a logical group, the value object, should be in the model or adapter. This way frontend and backend can decide on their own if they want to treat the concept of a “city” as an value object or just a bunch of attributes.

By putting this concept into the payload you introduce a pretty strong dependency which should probably have its own place in the database.

45

How is that considered an embedded record? That just seems like you added properties to the original record. I always thought embedded records were nested objects or nested arrays.

46

Not at all? I’m talking about the desire to have value objects. You have an address record with various attributes, a few of those attributes could be grouped into the concept of an “city”. That is called an value object and this concept shouldn’t be put into the transport layer.

47

Do you mean that the nested object shouldn’t be put in the transport layer? So everything should be flattened during serialization?

48

this all looks fantastic, I never liked ember data and how slow it’s being developed. What is the state of yours?

49

Well, I’m using it in a production application for work, so that should give you some idea. I would call it ‘usable’. It certainly has bugs, but nothing too huge. If you report a bug to me, I’ll try my absolute best to have it fixed within a day. And because I’m using this for work, and work is somewhat sponsoring it’s development, development progresses fairly quickly. I’m not saying I work on it every day, but part of my job is ensuring that this library fits our needs, so I inevitably have to work at least 10 hours a week on it.

To put it plainly: work on Ember-Graph has been picking up lately, and I have no intentions of slowing it down.

50

This is pretty exciting. Still too shaky with Ember to be much use to you now, but long term, I am going to need something like this.

51

gordon,

Are there any plans on accomodating any sorting/pagination/dynamic-query functions through the model layer here? I know I am in sorry need of controlling that stuff server-side rather than client-side. Is that even a feasible thing to do?