Hi @gordon, thanks for your answer. Let me give you some details:
- I don’t agree with you on that. In the main PHP ORM, you can find the documentation of so-called “embeddable” (http://doctrine-orm.readthedocs.org/en/latest/tutorials/embeddables.html). They really allow you to decouple your code, where it does not make sense to have a separate table (either for performance issue or for avoiding too many tables).
For instance, you could have an IpAddress, where you may want to store the IP and the subnet mask. Of course, you could create a separate table just for storing that but this is overkill. At the same time, you don’t want to duplicate the “ip” and “subnet” in all your models that store an IP address.
Isntead, you create an Embeddable object (sorry, I’m reusing Doctrine 2 terminology here), called IpAddress, where you have two fields. The two fields (ip and subnet) will be stored in the same table, but what you will receive as payload is:
{“id”: 54, “country”: “FR”, “city”: “Paris”, “ip”: {“part”: “123.45.46.45”, “subnet”: “16”}}
As you can see, the embeddable is not persisted on its own, but contained within the same table, but “act” as a separate object.
There are actually quite a lot of cases where it makes a lot of sense! Of course, it can be written with a custom type, but that seems more like a hack rather than an actual solution, because if I design my application using embedded properties like that, I actually want to consider the “Ip” like a separate model, as it was designed like this server-side.
-
Too bad :(. I know EPF but they do not cover nested URL neither. Just a stupid question: how do you handle such cases? I mean, it seems like really an essential feature, and I’ve seen a lot of cases where updating an input field just destroyed completely the whole UI by changing all the other fields in real-time in the interface, so that the user may think that it is saved in real time, where it is actually not. Do you modify your design so that bound properties of a model are never shown together with a form?
-
Yep. Nested URLs is another thing I don’t know how you can live without :D. It’s by far the most frustrating part in Ember-Data. A discussion has been open for that several months ago but it seems there is no news (Nested URLs for Ember Data's RestAdapter proposal).
Use case is… well… nearly all my API is nested. I think the Stripe API is a good example of nested API. For instance, if you want to create a new subscription for a given customer, you POST to “/customers/45/subscriptions”. If you want to get all subscriptions for a given customer, you do GET “/customers/45/subscriptions”.
I honestly do not see any other ways to represent that kind of things. Of course you could GET “/subscriptions?customer=45” but that’s not correct imho. The subscriptions belongs to the customers, so it’s not “filtering by customer”, but rather getting subscriptions for customer.
Most of the time, a nested of one level (“/foo/:foo-id/bar”) is enough, because if you nest more (“/customers/45/subscriptions/56/invoices”) can be rewritten “/subscriptions/56/invoices”.
There are a lot of proposal syntaxes in the mentioned thread, don’t hesitate to have a look at it :).
Sorry for all the feedbacks and complaints, I’d love to help but JS is really not my best language. But I’ve worked and built a lot of API and I feel frustrated not finding a library that covers all the use cases =).