Seems the idea is :-1: from core. Won't be accepted. Thanks for the consideration, please move discussion to railscore-talk.
-- Richard Sent from the road On Wednesday, September 19, 2012 at 11:32 PM, Pascal Hurni wrote: > I would even go further on this case, have the web server extract the api > version and proxy to the correct app instance. > Of course it may use a bit more server resources but the ease of deployment > and bug fixes (in each supported version) is so high, and no more 'if's ;-) > > (Just thinking out loud) > > Regards, > > Le 20.09.12 04:51, Ben Willis a écrit : > > I see your point Ryan, but if you have different code paths for different > > versions the 'if' logic has to go somewhere. Most of the other approaches > > will push the conditional into your routes file which makes it more > > difficult to dry your controller logic. Ideally you do not need to have > > these code paths at all and the only thing changing is the view of the > > payload. > > > > On Wed, Sep 19, 2012 at 6:28 PM, Ryan Bigg <[email protected] > > (mailto:[email protected])> wrote: > > > 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]> 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 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] > > > (mailto:[email protected]). > > > To unsubscribe from this group, send email to > > > [email protected] > > > (mailto:rubyonrails-core%[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] > > (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. -- 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.
