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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
[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 <jim.jones1@gmail.com> 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
I don''t think this is a feature for rails. There is not only jbuilder. Take a look, for example, at ActiveModel Serializers : https://github.com/josevalim/active_model_serializers Which is, in my opinion, better than jbuilder, and where you don''t have views for your json at all. Also, in an API, versioning the rendering is not enough. You need to be able to version features if necessary. There are several existing solutions for this already, a bit different from yours. For example, biceps, which allows routing different versions differently. https://github.com/lyonrb/biceps Damien MATHIEU | Ingénieur logiciel 84, rue Chevreul | 69 007 Lyon Tel. : +33 (0)6 88 42 00 15 | http://dmathieu.com On 15 September 2012 11:18, Jim Jones <jim.jones1@gmail.com> 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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 <radarlistener@gmail.com> 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 <jim.jones1@gmail.com> 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Thanks for the feedback guys.> In my experience, however, it''s usually more than just the view thatchanges 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 <radarl...@gmail.com <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 <jim.j...@gmail.com <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 rubyonra...@googlegroups.com<javascript:> > . > To unsubscribe from this group, send email to > rubyonrails-co...@googlegroups.com <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 rubyonra...@googlegroups.com<javascript:> > . > To unsubscribe from this group, send email to > rubyonrails-co...@googlegroups.com <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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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 <radarl...@gmail.com (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 <jim.j...@gmail.com (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 rubyonra...@googlegroups.com (javascript:). > > > > To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com (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 rubyonra...@googlegroups.com (javascript:). > > > To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com (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 rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com). > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com (mailto:rubyonrails-core+unsubscribe@googlegroups.com). > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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 <radarlistener@gmail.com> 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 <radarl...@gmail.com> 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 <jim.j...@gmail.com> wrote: > > My friend Ben Willis and I have developed a gem for the versioning of > Rails views. > https://github.com/bwillis/**versioncake<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<https://groups.google.com/d/msg/rubyonrails-core/-/9POep66BvoMJ> > . > To post to this group, send email to rubyonra...@googlegroups.**com. > To unsubscribe from this group, send email to rubyonrails-co...@** > googlegroups.com. > For more options, visit this group at http://groups.google.com/** > group/rubyonrails-core?hl=en<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 rubyonra...@googlegroups.**com. > To unsubscribe from this group, send email to rubyonrails-co...@** > googlegroups.com. > For more options, visit this group at http://groups.google.com/** > group/rubyonrails-core?hl=en<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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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 <radarlistener@gmail.com > <mailto:radarlistener@gmail.com>> 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 <radarl...@gmail.com> 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 <jim.j...@gmail.com> 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 rubyonra...@googlegroups.com. >>>>> To unsubscribe from this group, send email to >>>>> rubyonrails-co...@googlegroups.com. >>>>> 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 rubyonra...@googlegroups.com. >>>> To unsubscribe from this group, send email to >>>> rubyonrails-co...@googlegroups.com. >>>> 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 >> rubyonrails-core@googlegroups.com >> <mailto:rubyonrails-core@googlegroups.com>. >> To unsubscribe from this group, send email to >> rubyonrails-core+unsubscribe@googlegroups.com >> <mailto:rubyonrails-core+unsubscribe@googlegroups.com>. >> 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 > rubyonrails-core@googlegroups.com > <mailto:rubyonrails-core@googlegroups.com>. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com > <mailto:rubyonrails-core%2Bunsubscribe@googlegroups.com>. > 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
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 <radarlistener@gmail.com (mailto:radarlistener@gmail.com)> 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 <radarl...@gmail.com> 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 <jim.j...@gmail.com> 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 rubyonra...@googlegroups.com. > > > > > > > To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com. > > > > > > > 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 rubyonra...@googlegroups.com. > > > > > > To unsubscribe from this group, send email to rubyonrails-co...@googlegroups.com. > > > > > > 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 rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com). > > > > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com (mailto:rubyonrails-core+unsubscribe@googlegroups.com). > > > > 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 rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com). > > > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com (mailto:rubyonrails-core%2Bunsubscribe@googlegroups.com). > > > 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 rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com). > > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com (mailto:rubyonrails-core+unsubscribe@googlegroups.com). > > 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Thu, Sep 20, 2012 at 9:19 AM, Richard Schneeman < richard.schneeman@gmail.com> wrote:> Seems the idea is :-1: from core. Won''t be accepted. Thanks for the > consideration, please move discussion to railscore-talk. >I would like to add one thing. I''m also not a big fan of such versioning, but if you still think that people would benefit from using it, you could release it as a gem. If rails lack any extension mechanism that''s needed to add it, we will happily merge pull requests with fixes. Also, when we code for the gem is available and we can see how much needs to be changed in practice, we can talk again - maybe some of the features would be useful for other use cases as well.> > -- > 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 <radarlistener@gmail.com>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 <radarl...@gmail.com> 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 <jim.j...@gmail.com> 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 rubyonra...@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-co...@googlegroups.com. > 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 rubyonra...@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-co...@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > 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 rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to > rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/rubyonrails-core?hl=en. >-- Piotr Sarnacki http://piotrsarnacki.com -- 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 rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
Piotr - This pattern has worked very well for our current system and we believe that others would benefit from it. The gem has already been released (VersionCake). The link to the source is listed in the first message of the discussion. Jim Jones http://www.github.com/aantix On Thursday, September 20, 2012 8:21:06 AM UTC-7, Piotr Sarnacki wrote:> > > > On Thu, Sep 20, 2012 at 9:19 AM, Richard Schneeman <richard....@gmail.com<javascript:> > > wrote: > >> Seems the idea is :-1: from core. Won''t be accepted. Thanks for the >> consideration, please move discussion to railscore-talk. >> > > I would like to add one thing. I''m also not a big fan of such versioning, > but if you still think that people would benefit from using it, you could > release it as a gem. If rails lack any extension mechanism that''s needed to > add it, we will happily merge pull requests with fixes. > > Also, when we code for the gem is available and we can see how much needs > to be changed in practice, we can talk again - maybe some of the features > would be useful for other use cases as well. > > >> >> -- >> 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 <radarl...@gmail.com<javascript:> >> > 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 <radarl...@gmail.com> 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 <jim.j...@gmail.com> 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 rubyonra...@googlegroups.com. >> To unsubscribe from this group, send email to >> rubyonrails-co...@googlegroups.com. >> 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 rubyonra...@googlegroups.com. >> To unsubscribe from this group, send email to >> rubyonrails-co...@googlegroups.com. >> 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 rubyonra...@googlegroups.com<javascript:> >> . >> To unsubscribe from this group, send email to >> rubyonrails-co...@googlegroups.com <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 rubyonra...@googlegroups.com<javascript:> >> . >> To unsubscribe from this group, send email to >> rubyonrails-co...@googlegroups.com <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 rubyonra...@googlegroups.com<javascript:> >> . >> To unsubscribe from this group, send email to >> rubyonrails-co...@googlegroups.com <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 rubyonra...@googlegroups.com<javascript:> >> . >> To unsubscribe from this group, send email to >> rubyonrails-co...@googlegroups.com <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 rubyonra...@googlegroups.com<javascript:> >> . >> To unsubscribe from this group, send email to >> rubyonrails-co...@googlegroups.com <javascript:>. >> For more options, visit this group at >> http://groups.google.com/group/rubyonrails-core?hl=en. >> > > > > -- > Piotr Sarnacki > http://piotrsarnacki.com >-- 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/-/pEl_KMQr42AJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.