Skip to content
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

Open
apsoto opened this issue Apr 3, 2013 · 8 comments
Open
Labels

Comments

@apsoto
Copy link
Contributor

apsoto commented Apr 3, 2013

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.

@gxxcastillo
Copy link
Contributor

I'm not sure I understand. Could you provide an example?

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.

@apsoto
Copy link
Contributor Author

apsoto commented Apr 9, 2013

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.

@apsoto
Copy link
Contributor Author

apsoto commented Apr 12, 2013

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,
  ...
}

@gxxcastillo
Copy link
Contributor

Nice. For now I'm thinking its worth having the flexibility to declare a classname that's not bound to name rel

@gxxcastillo
Copy link
Contributor

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:

Backbone.Siren.settings.classMap = {
  'root#order-item' : window.myapp.models.OrderItem,
  ...
}

@apsoto
Copy link
Contributor Author

apsoto commented Apr 15, 2013

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.

@gxxcastillo
Copy link
Contributor

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...?

@apsoto
Copy link
Contributor Author

apsoto commented Apr 15, 2013

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants