I just wanted to chime in a second.

I agree this versioning is a little niche.

Is there, however, a neat public API in rails for gem authors to add in
lookup match parts for view lookup?

I.e is it possible to register (:apiversion) into lookup paths and have it
be handled by my class (ApiVersionPathHandler). Similar to the current
.format and .locale stuff in view file names

For me it might be about other things (regions, roles whatever my gem wants
to provide)

I am under the impression that these parts are not open to extension at
present.

Cheers

Sent from my iPhone

On 16 Sep 2012, at 21:21, Ryan Bigg <[email protected]> wrote:

[This email will arrive approx 15 hours after I've written it. Sorry if
there's been talk on this post by that stage that I am "ignoring"]

I'm not sure I can agree with such a feature being a part of Rails just
yet. There is currently many different approaches to designing APIs with
Rails, going from the very basic "render JSON" calls in the controllers, to
rabl and (god forbid, only because the syntax is really ugly) JBuilder, to
ActiveModel::Serializers and not to forget the new Rails::API gem thing
that Santiago Pastorino and co are working on.

My point is that there's all these different ways to do the design of the
API and, besides the default render call, none of these are core Rails
features. They're all external gems that offer their unique take on how to
"properly" design an API.

I can definitely see how, in a very small use case, versioning the views
for an API could be useful. In my experience, however, it's usually more
than just the view that changes between versions. The controller receives
customizations as well, sometimes.  Therefore, I think that versioning the
views is not a "majority case" and shouldn't be a core feature.

I think the best course of action here is to leave the functionality as a
gem and promote it as yet another alternative to designing an API with
Rails.

On 15/09/2012, at 19:18, Jim Jones <[email protected]> wrote:

My friend Ben Willis and I have developed a gem for the versioning of Rails
views.
https://github.com/bwillis/versioncake

The versioning is done by the naming convention.  Image the following
series of files :

show.v3.json.jbuilder
show.v2.json.jbuilder
show.v1.json.jbuilder

create.v2.json.jbuilder
create.v1.json.jbuilder

The developer pre-defines all view versions in their config.  When a
specific view version is specified (via a header or request param) , if the
version of that view exists, it is rendered, otherwise, the request
_degrades_ to the previous version.

This makes it really handy for APIs/Jbuilder views.  For example, if you
defined a new version for your API, e.g. v3, yet all other actions remain
the same, the degradation will automatically select the appropriate
backward compatible view (v2 for the create view above).

The versioning functionality is passive meaning that if the version file
extensions aren't utilized, the end user (especially beginners) will not
know that the functionality exists.

Our end goal is to merge and submit a pull request for Rails core.

Would love to hear everyone's thoughts.

Jim Jones
http://www.github.com/aantix

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-core/-/9POep66BvoMJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

 --
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Core" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.

-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/rubyonrails-core?hl=en.

Reply via email to