Ability to name Objective-C property differently than its JSON key

[christianselig]

Say I'm interfacing with an API that has an img_url key. If I'm understanding everything correctly, plank would incorporate that as imgUrl. It'd be nice to be able to specify it as imageURL to be more inline with Objective-C convention (I don't have server-side control over this API, so I can't change it there).

Or is there a goal to keep it absolutely 1:1 with the server-side spec?

[rahul-malik]

@christianselig - I'm assuming the convention you are trying to keep is the property suffix represented as URL vs Url. Is that correct?

Your understanding of how plank derives property names is almost correct.

• img_url is split into it's components separated by _ ([img, url])
• These components are compared against a Dictionary that has common reserved keywords that could be issues in generated code. Example - If the schema key was id we would produce code that wouldn't compile so we convert this to identifier.
• The first character of each component besides the first is capitalized ([img, Url]). There is an exception to this logic for url that will capitalize the entire component to URL.
• The components are concatenated back to a single name imgURL

Thanks for the suggestion and it has certainly come up internally at Pinterest before. Historically we've had a goal of keeping scheme keys 1:1 with the server-side specification to enforce the creation of reasonable keys for our API JSON responses.

A workaround we've used internally is to declare a property getter on a category on your model class which would look something like the below code.

// Generated model interface
@interface MyModel
@property (nonatomic, strong, readonly) NSURL *imgURL;
@end

// Your category
@interface MyModel(Aliases)
@property (nonatomic, strong, readonly) NSURL *imageURL;
@end

@implementation MyModel(Aliases)
- (NSURL *)imageURL 
{
  return self.imgURL;
}
@end

[christianselig]

@rahul-malik Your assumption was correct! And awesome, that's terrific and should suffice fine, thanks for the prompt response and appreciate the library. :)

[rahul-malik]

Thanks @christianselig! Let me know if you run into any issues :)