This seems a bit hacky. I don't like the idea of having conditionals in your controller actions to determine different code paths. That feels a bit like the olden days in PHP-land.
On Thursday, 20 September 2012 at 2:26 AM, Jim Jones wrote: > Thanks for the feedback guys. > > > 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. > > Ryan, we've updated our samples to show how changes to your API logic (per > version) can be accounted for in your controllers to ensure > backwards/forwards compatibility : > > class PostsController < ApplicationController > def index > # shared code for all versions > @posts = Post.scoped > > # version 3 or greated supports embedding post comments > if requested_version >= 3 > @posts = @posts.includes(:comments) > end > end > end > > It's just a simple comparison against the view version. > > The beauty of the view based APIs is that they allow you to easily reuse your > existing controller logic. Separating of API logic into their own > controllers doesn't have that advantage. > > So our solution covers both the controller, allowing you to make exceptions > to ensure forwards/backwards compatibility by simply checking against the > current version (please see our updated examples) and then the aforementioned > view version with degradation support. > > Jim Jones > http://www.github.com/aantix > > On Sunday, September 16, 2012 1:46:34 PM UTC-7, mrloz wrote: > > 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] (javascript:)> > > 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] (javascript:)> > > > 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] > > > > (javascript:). > > > > To unsubscribe from this group, send email to > > > > [email protected] (javascript:). > > > > 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] > > > (javascript:). > > > To unsubscribe from this group, send email to > > > [email protected] (javascript:). > > > 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 view this discussion on the web visit > https://groups.google.com/d/msg/rubyonrails-core/-/Oyigk16rMzwJ. > To post to this group, send email to [email protected] > (mailto:[email protected]). > To unsubscribe from this group, send email to > [email protected] > (mailto:[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.
