There is a function "resources" in the class "SingletonResource" that provides 7 routes for an indicated resource, like this: GET /photos GET /photos/:id etc. Also, there are some gems(as "friendly_id") that give a possibility to store an arbitrary string in :id parameter, what helps to have frendlier links like /photos/big-ben. But for several reasons this approach makes me feel odd. The fact that in the :id is stored, for example, a name of a model is not quite elegant. And also it leads to such code in controller: @photo = Photo.find_by_name(params[:id]) Which can be hardy called beautiful. "params[:name]" should fit much better. To avoid this, the gem mentioned above redefines the "find" method in choosen model, but I do not like it too. It can easily provoke gem conflicts, because there is a lot of gems that do it too. E.g., commonly a gem which adds "soft delete" also redefines this method that makes impossible to use them together or can break functionality somehow later. So, my suggestion is to add a :param_name option to "resources" method so we can have the behavior like this: resources :photos, :param_name => ''name'' GET /photos/:name Could it be useful if I add such feature? In addition, there is a whole bunch of questions on stackoveflow with the same desire. -- 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/-/tVhYzQMGufIJ. 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.
Hi Nickolas, Le 06.10.12 13:19, Nickolas a écrit :> > There is a function "resources" in the class "SingletonResource" that > provides 7 routes for an indicated resource, like this: > GET /photos > GET /photos/:id > etc. > > Also, there are some gems(as "friendly_id") that give a possibility to > store an arbitrary string in :id parameter, what helps to have > frendlier links like /photos/big-ben. > > But for several reasons this approach makes me feel odd. The fact that > in the :id is stored, for example, a name of a model is not quite > elegant. And also it leads to such code in controller: > > @photo = Photo.find_by_name(params[:id])Well, you as a developer may choose what the :id placeholder will contain. It''s not always the ''name'' of the model but any _identificator_ (a string one also) that will tie with your record. When using friendly_id, your controller code will be exactly the same as without the gem (it is its purpose) @photo = Photo.find(params[:id]) Now in the params hash the user may have put either a numeric id OR a friendly id (generally the user don''t write that, the route generation will do). In the context of friendly_id both are correct.> Which can be hardy called beautiful. "params[:name]" should fit much > better. To avoid this, the gem mentioned above redefines the "find" > method in choosen model, but I do not like it too. It can easily > provoke gem conflicts, because there is a lot of gems that do it too. > E.g., commonly a gem which adds "soft delete" also redefines this > method that makes impossible to use them together or can break > functionality somehow later. >There''s nothing wrong with params[:id] containing "rails-tutorial", this is a controller concern, the semantic is: "We have a request to find a resource identified with params[:id]". Nowhere in Rails we say that this id IS an ActiveRecord record''s id attribute. Of course for convenience and when using the whole stack, this last statement is what we want, but it''s our controller code that controls this semantic. For the issues of having multiple gems patching rails, this is another issue (or non issue when these gems are well written) (BTW, for soft deletes, use scopes instead)> So, my suggestion is to add a :param_name option to "resources" method > so we can have the behavior like this: > > resources :photos, :param_name => ''name'' > > GET /photos/:name > > Could it be useful if I add such feature? In addition, there is a > whole bunch of questions on stackoveflow with the same desire. >I''m -1 on this.> -- > 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/-/tVhYzQMGufIJ. > 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 Mon, Oct 8, 2012 at 8:58 AM, Pascal Hurni <hurnip@gmail.com> wrote:> > There''s nothing wrong with params[:id] containing "rails-tutorial", this > is a controller concern, the semantic is: "We have a request to find a > resource identified with params[:id]". Nowhere in Rails we say that this id > IS an ActiveRecord record''s id attribute. Of course for convenience and > when using the whole stack, this last statement is what we want, but it''s > our controller code that controls this semantic. >Technically it''s not wrong, but when it comes to readability, it''s much better to say params[:slug] or params[:name] if that''s what it is. I would like to have the ability to set the name of that param. Anyone from core team cares enough to accept/reject this idea? -- 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.
Isn''t this what to_param is for? -- 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.
He is talking about the other side when the URL parameters get deserialized into the params hash. You can alias the param name in a before_filter in your controller (or application controller if you need this everywhere): before_filter :alias_id private def alias_id params[:slug] = parmas.delete(:id) end I think the generalized version of this problem/pain point is that there doesn''t seem to be a good way to deserialize data coming into a rails app. For example, you might want to run certain parameters in your models through Base64.encode64 before you send them out as JSON, and would like to run them through Base64.decode64 when then come in as a parameter. Or perhaps you have a Money object that get serialized into a currency field and an amount field, and you''d like to convert back to a Money object for your controller code to work with. Seeing how active model serialize provides a neat way to do the serialization step, it only seems natural that we have an equally elegant way for the other direction as well. before filter works okay, but could be quite difficult to read/maintain/manage when you have a lot of them. On 2012-10-08, at 1:03 PM, Steve Klabnik wrote:> Isn''t this what to_param is for? > > -- > 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.
<div>Hi. </div><div> </div><div>I think that using <span style="font-family:"courier new",courier;"><span>resources</span><span>:photos</span><span>,</span><span>:param_name</span><span>=></span><span>''name''</span></span> has some sense.</div><div> </div><div>First, it allows me to put all this logic in config/routes.rb where it belongs.</div><div> </div><div>Second, it allows me to get beautiful route map: <span style="font-family:"courier new",courier;font-size:15px;line-height:21px;">GET /photos/:name</span><span style="font-family:"courier new",courier;font-size:15px;line-height:21px;"> </span>instead of <span style="font-family:"courier new",courier;font-size:15px;line-height:21px;">GET /photos/:id</span>.</div><div> </div><div>Third, it seems to me that Rails is all about aliasing and this feature would be pretty nice alias.</div><div> </div><div>09.10.2012, 00:40, "Godfrey Chan" <godfreykfc@gmail.com>:</div><blockquote type="cite">He is talking about the other side when the URL parameters get deserialized into the params hash.<div>You can alias the param name in a before_filter in your controller (or application controller if you need this everywhere):</div><div><span style="font-family:Courier;">before_filter :alias_id</span></div><div><span style="font-family:Courier;"><br /></span></div><div><span style="font-family:Courier;">private</span></div><div><span style="font-family:Courier;">def alias_id</span></div><div><span style="font-family:Courier;"> params[:slug] = parmas.delete(:id)</span></div><div><span style="font-family:Courier;">end</span></div><div><div>I think the generalized version of this problem/pain point is that there doesn''t seem to be a good way to deserialize data coming into a rails app. For example, you might want to run certain parameters in your models through Base64.encode64 before you send them out as JSON, and would like to run them through Base64.decode64 when then come in as a parameter. Or perhaps you have a Money object that get serialized into a currency field and an amount field, and you''d like to convert back to a Money object for your controller code to work with.</div><div>Seeing how active model serialize provides a neat way to do the serialization step, it only seems natural that we have an equally elegant way for the other direction as well. before filter works okay, but could be quite difficult to read/maintain/manage when you have a lot of them.</div><div><br /><div><div>On <span>2012-10-08</span>, at 1:03 PM, Steve Klabnik wrote:</div><br /><blockquote type="cite"><div>Isn''t this what to_param is for?<br /><br />-- <br />You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.<br />To post to this group, send email to <a href="mailto:rubyonrails-core@googlegroups.com">rubyonrails-core@googlegroups.com</a>.<br />To unsubscribe from this group, send email to <a href="mailto:rubyonrails-core+unsubscribe@googlegroups.com">rubyonrails-core+unsubscribe@googlegroups.com</a>.<br />For more options, visit this group at <a href="http://groups.google.com/group/rubyonrails-core?hl=en">http://groups.google.com/group/rubyonrails-core?hl=en</a>.<br /><br /></div></blockquote></div></div></div><p> </p>-- <br /> You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.<br /> To post to this group, send email to <a href="mailto:rubyonrails-core@googlegroups.com">rubyonrails-core@googlegroups.com</a>.<br /> To unsubscribe from this group, send email to <a href="mailto:rubyonrails-core+unsubscribe@googlegroups.com">rubyonrails-core+unsubscribe@googlegroups.com</a>.<br /> For more options, visit this group at <a href="http://groups.google.com/group/rubyonrails-core?hl=en">http://groups.google.com/group/rubyonrails-core?hl=en</a>.</blockquote> <p></p> -- <br /> You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.<br /> To post to this group, send email to rubyonrails-core@googlegroups.com.<br /> To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com.<br /> For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.<br />
> it seems to me that Rails is all about aliasingLOL... this made my day :D Sent from my phone -- 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.
It does only half of the job. It changes the content of the parameter passed, but not it''s name. The idea is to be able to change the name. On Tuesday, October 9, 2012 12:03:54 AM UTC+4, Steve Klabnik wrote:> Isn''t this what to_param is for? >-- 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/-/LUtlww5R_zoJ. 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.
-1 on this also for reasons Piotr explained. On 09/10/2012, at 8:13, Nickolas <sir.nickolas@gmail.com> wrote:> It does only half of the job. It changes the content of the parameter passed, but not it''s name. > The idea is to be able to change the name. > On Tuesday, October 9, 2012 12:03:54 AM UTC+4, Steve Klabnik wrote: >> Isn''t this what to_param is for? > -- > 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/-/LUtlww5R_zoJ. > 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.
But why? Reasons explained by Piotr are favourable for this patch. He said that the approach with before_filter is not quite elegant and he''d like to have a centralised way to rename resource id and do not repeat this code, for example, in every controller. вторник, 9 октября 2012 г., 1:47:47 UTC+4 пользователь Ryan Bigg написал:> -1 on this also for reasons Piotr explained. > > > > On 09/10/2012, at 8:13, Nickolas <sir.ni...@gmail.com <javascript:>> > wrote: > > It does only half of the job. It changes the content of the parameter > passed, but not it''s name. > The idea is to be able to change the name. > On Tuesday, October 9, 2012 12:03:54 AM UTC+4, Steve Klabnik wrote: > >> Isn''t this what to_param is for? >> > -- > 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/-/LUtlww5R_zoJ. > 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/-/hxqep6p3u3kJ. 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.
But reasons indicated by Piotr are favourable. Why? вторник, 9 октября 2012 г., 1:47:47 UTC+4 пользователь Ryan Bigg написал:> -1 on this also for reasons Piotr explained. > > > > On 09/10/2012, at 8:13, Nickolas <sir.ni...@gmail.com <javascript:>> > wrote: > > It does only half of the job. It changes the content of the parameter > passed, but not it''s name. > The idea is to be able to change the name. > On Tuesday, October 9, 2012 12:03:54 AM UTC+4, Steve Klabnik wrote: > >> Isn''t this what to_param is for? >> > -- > 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/-/LUtlww5R_zoJ. > 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/-/A5s4mpQiQmwJ. 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.
Pretty sure he meant Pascal On 2012-10-08, at 8:59 PM, Nickolas wrote:> But reasons indicated by Piotr are favourable. Why? > > вторник, 9 октября 2012 г., 1:47:47 UTC+4 пользователь Ryan Bigg написал: > -1 on this also for reasons Piotr explained. > > > > On 09/10/2012, at 8:13, Nickolas <sir.ni...@gmail.com> wrote: > >> It does only half of the job. It changes the content of the parameter passed, but not it''s name. >> The idea is to be able to change the name. >> On Tuesday, October 9, 2012 12:03:54 AM UTC+4, Steve Klabnik wrote: >> Isn''t this what to_param is for? >> >> -- >> 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/-/LUtlww5R_zoJ. >> 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/-/A5s4mpQiQmwJ. > 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.