Added a case converter plugin

[kripod]

The case converter plugin handles the conversion between the DB's snake_cased and JS's camelCased Model properties automatically.

It is not hard to implement manually by anyone, but as many people use similar code, I think that this functionality deserves its own official plugin.

[ricardograca]

There's been some talk about moving this functionality into core Bookshelf (not a plugin and not using parse and format) for some time. You can check out the conversations about that if you search for "format is confusing" and issues dealing with both methods.

I'm not saying this won't get accepted, but it's a bit against the general direction for the future, so let's see what the other guys think.

[kripod]

Thanks for the reply! Then, there could be a boolean option for initializing Bookshelf instances, indicating whether automatic case conversion should happen.

[vellotis]

@ricardograca Just to philosophically continue the converisation. What will be the future as this project is not actively developed but just maintained?

[ricardograca]

That question is in no way related to this issue, so please use the appropriate communication channels for that, like Gitter or a relevant GitHub issue.

[rhys-vdw]

@kripod Yeah, this is a great idea. I'd like simple test cases for this just to be sure. Also this should be documented as the default way to achieve this, leaving manual parse/format overrides as more "advanced" approaches.

@ricardograca I don't think that the idea of key conversion for records will go away, we'll just have to update/remove the plugin as the feature evolves.

[chamini2]

Is there any way to make the conversion functions parameters?

[chamini2]

Why not do instead:

parse: function(attrs) {
  return _.mapKeys(attrs, (, k) => _.camelCase(k));
}

[ricardograca]

I'll convert to that method after merging this, since the original author isn't interested in doing it.

[ricardograca]

@kripod If you can address the comment by the reviewer and provide some tests we can merge this.

[kripod]

@ricardograce I'm sorry, but unfortunately, I lost my interest for this project.

[ricardograca]

Merging this as is and then I'll add more documentation to it and change the method used as proposed by @chamini2. The difference in performance is negligible between the two, but it uses less code, and is not less readable, so there's that.

[ricardograca]

This is a good enough starting point.