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

relation should be able to get content from model attribute different then 'key' #60

Closed
4vanger opened this Issue Jan 3, 2012 · 7 comments

Comments

Projects
None yet
3 participants
@4vanger
Contributor

4vanger commented Jan 3, 2012

I'm having model like

var SomeModel = Backbone.RelationalModel.extend({
    relations: [
        {
            type: "HasOne",
            key: "item",
            relatedModel: 'ItemModel'
        }
    ]
});

Then I init this model with following JSON:

{
  id: 128,
  itemId: 356
}

So relation key is different from an attribute where ID is stored.
But I still want to keep relations - so when I change itemId - item will change. And vice versa - when I change item.id I'd like to update itemId attribute
What's the best way to get this behavior? I'm thinking on creating new Relation type that will have keyContentsAttribute option that will specify which model attribute to use. Is there better approach?

@PaulUithol

This comment has been minimized.

Show comment
Hide comment
@PaulUithol

PaulUithol Jan 6, 2012

Owner

Why do you want this, instead of just using itemId as the relation key (or using item in the data)?

Owner

PaulUithol commented Jan 6, 2012

Why do you want this, instead of just using itemId as the relation key (or using item in the data)?

@4vanger

This comment has been minimized.

Show comment
Hide comment
@4vanger

4vanger Jan 6, 2012

Contributor

to differentiate ID field (named itemId) from Model field (item).
Having such conventions for API makes it more predictable - you know when you see 'itemId' - it is an integer reference for Item model. And when you have 'item' in API - you know that it a model itself
In general - thanks for a great lib.

Contributor

4vanger commented Jan 6, 2012

to differentiate ID field (named itemId) from Model field (item).
Having such conventions for API makes it more predictable - you know when you see 'itemId' - it is an integer reference for Item model. And when you have 'item' in API - you know that it a model itself
In general - thanks for a great lib.

@arjes

This comment has been minimized.

Show comment
Hide comment
@arjes

arjes Feb 14, 2012

+1 for this.

I am working with a rails backend, and by convention they provide the id in the _id field (or _ids for a many), while the models themselves come via <key>

Its a great lib, I am working on a more Rails like interface to put above it, and I am going to try monkey patching it to get the desired behavior.

arjes commented Feb 14, 2012

+1 for this.

I am working with a rails backend, and by convention they provide the id in the _id field (or _ids for a many), while the models themselves come via <key>

Its a great lib, I am working on a more Rails like interface to put above it, and I am going to try monkey patching it to get the desired behavior.

@PaulUithol

This comment has been minimized.

Show comment
Hide comment
@PaulUithol

PaulUithol Feb 27, 2012

Owner

Okay, sounds like a good feature to me and I have some time to do this. Would serializationKey be a good name for the option, or does anyone have another proposal? The behavior would be along the following lines:

  1. When data gets loaded (basically, on set), the contents of the serializationKey are used as the keyContents for a relation.
  2. The client application uses the regular key attribute to interface with the relation and the models in it; the serializationKey is not available as an attribute for the model.
  3. When calling toJSON, the includeInJSON options are applied to key, and the results are assigned to the serializationKey.
Owner

PaulUithol commented Feb 27, 2012

Okay, sounds like a good feature to me and I have some time to do this. Would serializationKey be a good name for the option, or does anyone have another proposal? The behavior would be along the following lines:

  1. When data gets loaded (basically, on set), the contents of the serializationKey are used as the keyContents for a relation.
  2. The client application uses the regular key attribute to interface with the relation and the models in it; the serializationKey is not available as an attribute for the model.
  3. When calling toJSON, the includeInJSON options are applied to key, and the results are assigned to the serializationKey.
@4vanger

This comment has been minimized.

Show comment
Hide comment
@4vanger

4vanger Feb 27, 2012

Contributor

As for me "serializationKey" is somewhat opposite to original case (deserialization) and also is too long to type.
What about "keyValue", "keySource", "keyDestination"

Contributor

4vanger commented Feb 27, 2012

As for me "serializationKey" is somewhat opposite to original case (deserialization) and also is too long to type.
What about "keyValue", "keySource", "keyDestination"

@PaulUithol

This comment has been minimized.

Show comment
Hide comment
@PaulUithol

PaulUithol Feb 27, 2012

Owner

Hmm.. keyValue is a bit too generic for my taste (and you usually have a key that points to a value). Source and destination suffer from the same problem as serializationKey; both indicate just one use as well (either deserialization or serialization). Maybe serverKey/keyServer (as opposed to the one the client uses)? Although I do like keySource as well, despite mainly indicating deserialization.

Owner

PaulUithol commented Feb 27, 2012

Hmm.. keyValue is a bit too generic for my taste (and you usually have a key that points to a value). Source and destination suffer from the same problem as serializationKey; both indicate just one use as well (either deserialization or serialization). Maybe serverKey/keyServer (as opposed to the one the client uses)? Although I do like keySource as well, despite mainly indicating deserialization.

@PaulUithol

This comment has been minimized.

Show comment
Hide comment
@PaulUithol

PaulUithol Feb 27, 2012

Owner

I think I like keySource best, actually. In any case, you'll always be deserializing your app from some datasource to start out with.

Owner

PaulUithol commented Feb 27, 2012

I think I like keySource best, actually. In any case, you'll always be deserializing your app from some datasource to start out with.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment