-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Figure out a way to use a defined Model class when resolving entities #13
Comments
Nm. I got what you mean. Yeah, currently there are no defined model "classes". This was in an attempt to keep things as simple as possible while also trying to avoid coupling to server side "types". With that said, Its quite likely I've gone about that the wrong way. Eventually, when the need arises (e.g. when adding models/entities to a collection) I'd be open to ideas on how to best address this. |
So far I've been able to work around this, so not a must have at this point, but here's my idea: Iterate through the list of classes on the response and the first one that resolves to a Backbone.Siren.Model derived class use that otherwise use Backbone.Siren.Model. |
Thanks to @kevinswiber's comment on #15 maybe api can provide a clue via a rel: urn:x-resource:class:CLASSNAME or just use the same name rel ( #15 ) ? Ultimately, it's up to the client to turn the class name into something it can use because the api can't account for all client technology stacks. A bbSiren user would need to provide a classname to bbSiren Model mapping. Backbone.Siren.settings.classMap = {
'order-item' : window.myapp.models.OrderItem,
...
} |
Nice. For now I'm thinking its worth having the flexibility to declare a classname that's not bound to name rel |
If we have deep linking capabilities, as mentioned in #16, what if we drop the need for classname altogether...? You could have a map that looks like:
|
I think the CLASSNAME rel and the deep link are two different things. The deep link is similar to the locator for the NAME rel we added. The CLASSNAME is the resource type. |
I follow you but was trying to look for a way that would not require the server to specify a resource type to the client. I remember reading in a few places that this was usually frowned upon...? |
Good idea, I was being lazy since we already added a name: rel. However, the client needs a clue as to what model class to use. We could use any rel in the response and it's up to the developer to map it to a bbSiren model class. Backbone.Siren.settings.classMap = {
"http://x.io/rels/customer" : window.myapp.models.Customer
} If the response doesn't have a matching rel, then it just uses the standard bbSiren base class like it currently does. |
I noticed that I added a method to a model class, but when I reference the model via a sub-entity it's a generic Backbone.Siren.Model, so none of the methods I defined are accessible.
I'm not sure how this can be determined unless there's some rel -> class mapping or it's inferred via the class attribute of an entity.
So far it hasn't been a killer for me, but thought I'd document this issue as a nice to have.
The text was updated successfully, but these errors were encountered: