I''m currently using map.namespace to set the name_prefix to "admin/". Doing this appears to break polymorphic_url (and thus form_for, url_for, etc) as it isn''t taking name_prefix into account. Quick hack would be to allow polymorphic_url to accept a namespace or name_prefix argument. Does anyone else have any better ideas to make this work? Josh -- Josh Knowles joshknowles@gmail.com http://joshknowles.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 -~----------~----~----~----~------~----~------~--~---
Hi Josh,> I''m currently using map.namespace to set the name_prefix to > "admin/". Doing this appears to break polymorphic_url (and thus > form_for, url_for, etc) as it isn''t taking name_prefix into > account. Quick hack would be to allow polymorphic_url to accept a > namespace or name_prefix argument. Does anyone else have any > better ideas to make this work?I''m not sure a namespace or name_prefix argument will work in all cases... consider that you could have namespaces and resources nested to any number of levels. I was thinking that a syntax like the following might work though: # routes.rb map.namespace :admin do |a| a.resources :workshops do |w| w.resources :sessions end end # views <%= url_for([:admin, @workshop, @session]) %> <%= link_to(''Session'', [:admin, @workshop, @session]) %> <% form_for([:admin, @workshop, @session] do |f| %> # ... <% end %> The symbol would correspond to the namespace, and could be made to handle nested namespaces. -- Thanks, Dan __________________________________________________________________ Dan Kubb Autopilot Marketing Inc. Email: dan.kubb@autopilotmarketing.com Phone: 1 (604) 820-0212 Web: http://autopilotmarketing.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 -~----------~----~----~----~------~----~------~--~---
I''d apply a patch which would Dan''s style work. Please do investigate :)> > # routes.rb > map.namespace :admin do |a| > a.resources :workshops do |w| > w.resources :sessions > end > end > > # views > <%= url_for([:admin, @workshop, @session]) %> > <%= link_to(''Session'', [:admin, @workshop, @session]) %> > <% form_for([:admin, @workshop, @session] do |f| %> > # ... > <% end %> > > The symbol would correspond to the namespace, and could be made to > handle nested namespaces.-- Tobi http://shopify.com - modern e-commerce software http://typo.leetsoft.com - Open source weblog engine http://blog.leetsoft.com - Technical weblog --~--~---------~--~----~------------~-------~--~----~ 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 6/8/07, Dan Kubb <dan.kubb@autopilotmarketing.com> wrote:> > > > > I was thinking that a syntax like the following might work though: > > # routes.rb > map.namespace :admin do |a| > a.resources :workshops do |w| > w.resources :sessions > end > end > > # views > <%= url_for([:admin, @workshop, @session]) %> > <%= link_to(''Session'', [:admin, @workshop, @session]) %> > <% form_for([:admin, @workshop, @session] do |f| %> > # ... > <% end %>While I''m not a huge fan of the explicit array, it does fit with the current approach for handling nested resources. I got a version working last night which took a :name_prefix in the options, this should be easily adjusted to handle this case. In the example above would it really be :admin, or would it need to be ''admin_'' matching the appropriate namespace? More specifically, do you assume the ''_'', or do you just use the literal string which would account for multiple nested namespaces? Josh -- Josh Knowles joshknowles@gmail.com http://joshknowles.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 -~----------~----~----~----~------~----~------~--~---
It''s really frustrating to see how much stuff is being bolted on here. I''ve already written at length about how edge-cases (poly* resources) are being allowed to infect simpler cases: http://rubyurl.com/jzN And with this suggestion it just keeps getting worse. By far the simplest and most common case is this: form_for @something do ... end That''s easy. You haven''t told form_for what the url is so it will best-guess it using @something.class and @something.new_record? That doesn''t work for you because you''re doing something unusual with name_prefix or you''ve got a deeply nested resource? Sucks to be you for doing something complicated: form_for @something, :url => polymorphic_path(@parent, @of, @something, :namespace => :something_arbitrary) do ... end form_for *already* has a facility to supply a url that overrides any guesswork. And did you see how polymorphic_path can have a richer interface? Trying to ram a rich set of arguments down the throat of form_for by wrapping stuff up in an array is just plain ugly. Take a look at this: url_for([@parent, @child]) You know you want polymorphic_url to be called so you wrap up your arguments into an array so that they''ll get passed through. Then polymorphic_url tries to guess the url helper to be invoked. It builds a string based on the class of each argument because the auto-name_prefix convention demands it (otherwise it could just use the class of @child). Then polymorphic_url calls the parent_child_url() helper, passing the arguments through. parent_child_helper() unpacks the arguments into a single options hash and then calls... wait for it .... url_for(). Compare the two: url_for([@parent, @child]) polymorphic_url(@parent, @child) Seriously, what''s clearer and easier to explain to a newcomer? Save us all and stop trying to tunnel arguments to polymorphic_xxx through the method signature of url_for and form_for. Trevor On 6/8/07, Tobias Lütke <tobias.luetke@gmail.com> wrote:> > I''d apply a patch which would Dan''s style work. > > Please do investigate :) > > > > > # routes.rb > > map.namespace :admin do |a| > > a.resources :workshops do |w| > > w.resources :sessions > > end > > end > > > > # views > > <%= url_for([:admin, @workshop, @session]) %> > > <%= link_to(''Session'', [:admin, @workshop, @session]) %> > > <% form_for([:admin, @workshop, @session] do |f| %> > > # ... > > <% end %> > > > > The symbol would correspond to the namespace, and could be made to > > handle nested namespaces. > > > -- > Tobi > http://shopify.com - modern e-commerce software > http://typo.leetsoft.com - Open source weblog engine > http://blog.leetsoft.com - Technical weblog > > > >-- -- Trevor Squires http://somethinglearned.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 -~----------~----~----~----~------~----~------~--~---
> It''s really frustrating to see how much stuff is being bolted on here.While you may find this particular situation frustrating, I think it''s important to remember that everyone here is trying to achieve the same thing. A kickass web development framework. I definitely think we need to be cautious about just how much we cram into these polymorphic situations, and perhaps we should take some out, but lets try and keep the tone of this list positive, and not assume malice or enterpriseyness on the part of a participant. -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Koz, I''m not assuming *any* malice or enterpriseyness here at all. I *know* that everyone has the best of intentions and that everyone involved in this is smart (in case that is being called into question but not being stated). So in order to ensure the technical content of what I''m saying isn''t derailed by my tone: If I have offended anyone then I unequivocally aplogize; my email *was* harsh. It may help to know that I meant to hit "Save Now" and reread everything :-( I would be very grateful if you could read beyond the overall tone and examine the technical merits of what I''m saying. Trevor On 6/8/07, Michael Koziarski <michael@koziarski.com> wrote:> > > It''s really frustrating to see how much stuff is being bolted on here. > > While you may find this particular situation frustrating, I think it''s > important to remember that everyone here is trying to achieve the same > thing. A kickass web development framework. > > I definitely think we need to be cautious about just how much we cram > into these polymorphic situations, and perhaps we should take some > out, but lets try and keep the tone of this list positive, and not > assume malice or enterpriseyness on the part of a participant. > > > -- > Cheers > > Koz > > > >-- -- Trevor Squires http://somethinglearned.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 -~----------~----~----~----~------~----~------~--~---
> I would be very grateful if you could read beyond the overall tone and > examine the technical merits of what I''m saying.I think that you may be right, we have to balance the ''neat'' factor of having namespaces and polymorphic urls and the like magically working, with the need to have an understandable and ''obvious'' api. Leaving aside implementation, what would a simpler api look like in your mind? -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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''ve already written at length about how edge-cases (poly* resources) > are being allowed to infect simpler cases:One man''s edge case is another''s simple case. For me, polymorphic nested routes are common. I have stuff like /companies/1/tags and / people/1/tags as well as /people, /people/1, and /companies/6/people.> Trying to ram a rich set of arguments down the throat of form_for by > wrapping stuff up in an array is just plain ugly.I don''t think it is. I think it''s just using form_for as a delegate for url_for and ultimately polymorphic routes. I see nothing wrong with that. It''s building on top of what we already have for the more involved cases while not complicating the simpler cases that already works today.> url_for([@parent, @child]) > polymorphic_url(@parent, @child) > > Seriously, what''s clearer and easier to explain to a newcomer?url_for is not intended to be used like this directly. It''s just used as a gateway to polymorphic_url when called from higher-level helpers. So there will be no explanation needed.> Save us all and stop trying to tunnel arguments to polymorphic_xxx > through the method signature of url_for and form_for.I disagree. I think the majority of the hurt you''re experiencing is coming from the fact that whatever application you''ve worked on didn''t deal with multiple paths to the same models, like /people (all people) and /companies/5/people (just the people for company 6). All the applications I''ve worked with deal with multiple paths to the same models. So that''s what I''ve been involved with extracting. None of this stuff is about thought experiments, this is being extracted from real applications. Naturally, none of this can fit all scenarios all the time. Which is why I really enjoy the layered approach we have. You''re free to almost at any spot to do something different than what''s baked into the framework. Even stuff like :has_many resources is just a thin wrapper that calls resource methods you can almost as easily call yourself. In any case, it''s great to hear about other use cases, but I would recommend (as Koz did earlier) that you turn down the tone of your arguments. The blog posting you link to is at least as inflammatory as your post to this group. Which is completely unnecessary. We''re just interested in hearing about experiences. The louder you shout, the lower we''ll set the volume on our attention. And that would be a shame as you do seem to have some relevant inputs on this discussion. I''d hate to see them disregarded entirely because of your choice of words. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
David,> The louder you shout, the lower we''ll set the volume on our attention.Thank you for taking the time to read what I''ve written despite my earlier tone.> > > I''ve already written at length about how edge-cases (poly* resources) > > are being allowed to infect simpler cases: > > One man''s edge case is another''s simple case. For me, polymorphic > nested routes are common. I have stuff like /companies/1/tags and / > people/1/tags as well as /people, /people/1, and /companies/6/people. >There''s a much better opportunity to explain my position on ''edge-case'' below.> > Trying to ram a rich set of arguments down the throat of form_for by > > wrapping stuff up in an array is just plain ugly. > > I don''t think it is. I think it''s just using form_for as a delegate > for url_for and ultimately polymorphic routes. I see nothing wrong > with that. It''s building on top of what we already have for the more > involved cases while not complicating the simpler cases that already > works today. > > > url_for([@parent, @child])<SNIP>> url_for is not intended to be used like this directly. It''s just used > as a gateway to polymorphic_url when called from higher-level helpers. > So there will be no explanation needed. >I''d appreciate it if you would consider a couple of points: * using url_for is already being described as a way to offset the changes introduced by auto-name_prefix (I link to 2 such articles in my blog post). * form_for does not use url_for as a gateway as you stated - it (imho) *correctly* uses polymorphic_path() to generate the url My feeling is that url_for should not delegate to polymorphic_url as it does now. If you want a polymorphic url or path, you should ask for one. This would also help to concentrate any efforts to enrich form_for() in the right spot - polymorphic_xxx(). That way you would not have to try to overcome url_for''s interface. I believe these interface issues transcend any differences we may have (below) over polymorphics/polynymics and auto-name_prefix.> I disagree. I think the majority of the hurt you''re experiencing is > coming from the fact that whatever application you''ve worked on didn''t > deal with multiple paths to the same models, like /people (all people) > and /companies/5/people (just the people for company 6).On the contrary, I have *plenty* of situations like that (it''s what I extracted resource_fu from). I don''t do it as a matter-of-course to satisfy a convention such as "only-1-layer-deep". For example, if ''all people'' (/people) is not a meaningful concept for the application then I don''t create a resource for it. But when it has a place, I willingly use it. My issue is not so much whether there are applications out there with multiple paths to the same models, it''s the impact of trying to automatically accommodate them. Polymorphic and Polynymic resources are by their very nature, DRY. So even though you have multiple paths to the same model, I''m guessing that you re-use many of the same actions/templates over and over. With that in mind, consider this contrived example application: map.resources :houses do |house| house.resources :walls, :has_many => :damages house.resources :windows, :has_many => :damages house.resources :doors, :has_many => :damages house.resources :damages end The :damages resource appears four times, touching every other resource and the entire application seems to hinge on the concept Damage. However, in terms of template and controller lines, Damage probably (simplistically) only accounts for about 20% the application total. This is why I say that in my code poly* are an edge case and that I have far fewer poly* resources than non-poly* ones. It''s an opinion borne out of counting relevant lines of code. As such, I consider that anything the framework does to make Damage easier in this application isn''t nearly as big a win as making Houses, Walls, Windows and Doors easier. Of course I''m completely willing to accept that my experiences are unique. Regards, Trevor -- -- Trevor Squires http://somethinglearned.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 -~----------~----~----~----~------~----~------~--~---
> * using url_for is already being described as a way to offset the > changes introduced by auto-name_prefix (I link to 2 such articles in > my blog post).People also used to talk about how to use with_scope in filters. Just because some folks get it wrong in the early days of an API doesn''t mean the solution is a changed API.> * form_for does not use url_for as a gateway as you stated - it (imho) > *correctly* uses polymorphic_path() to generate the url > > My feeling is that url_for should not delegate to polymorphic_url as > it does now. If you want a polymorphic url or path, you should ask > for one.I agree. You should never call url_for directly with the [] syntax. That form of calling url_for is for helpers. Such that all helpers that delegate to url_for can link to nested poly resources easily.> This would also help to concentrate any efforts to enrich form_for() > in the right spot - polymorphic_xxx(). That way you would not have to > try to overcome url_for''s interface.It''s not really about url_for, it''s about the delegation that goes through it. None of this is to enrich url_for for public consumption.> The :damages resource appears four times, touching every other > resource and the entire application seems to hinge on the concept > Damage. > > However, in terms of template and controller lines, Damage probably > (simplistically) only accounts for about 20% the application total.First of all, I hate contrived examples. You can make a contrived example prove anything. I''m really only interested in discussion real code. Despite that, I still think that declaration is fine. First of all, routes.rb shouldn''t reflect the size of the underlying code base. It''s about reflecting the resources exposed. Damages are exposed as 4 different base resources, walls for example only as one. Thus, it''s fair for damages to take up more configuration space. Second, we already have a fair number of techniques to deal with duplication like this. For example: map.resources :houses do |house| house.resources :damages house.with_options(:has_many => :damages) do |fragile| fragile.resources :walls fragile.resources :windows fragile.resources :doors end end But if you have a suggestion for an API that wraps this cleaner, but doesn''t change the underlying generated routes, by all means shoot.> This is why I say that in my code poly* are an edge case and that I > have far fewer poly* resources than non-poly* ones. It''s an opinion > borne out of counting relevant lines of code.I believe that you''re counting impact in the wrong place. Think of routes.rb as dealing with the impact of resources and URLs exposed and giving damage a premiere spot makes perfect sense (it''s by far the most complex resource exposed). (P.S.: The tone of this exchange was much improved. Thank you for paying attention to this.) --~--~---------~--~----~------------~-------~--~----~ 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 6/11/07, DHH <david.heinemeier@gmail.com> wrote:> It''s not really about url_for, it''s about the delegation that goes > through it. None of this is to enrich url_for for public consumption.Okay, I understand and agree with that. I haven''t come across any spots where the framework "delegates through" url_for as we''re describing. I can only find form_for() that delegates through polymorphic_path(). Would you consider a patch which removed this behavior (as un-needed) from url_for?> > First of all, I hate contrived examples. You can make a contrived > example prove anything. I''m really only interested in discussion real > code. Despite that, I still think that declaration is fine.I hate them too - but I''m not in a position to show any real code so I tried to put something together that reflected the ratios in my own code.> > First of all, routes.rb shouldn''t reflect the size of the underlying > code base. It''s about reflecting the resources exposed. Damages are > exposed as 4 different base resources, walls for example only as one. > Thus, it''s fair for damages to take up more configuration space.I definitely agree that it''s fair for damages to take up more configuration space - that''s actually my point.> But if you have a suggestion for an API that wraps this cleaner, but > doesn''t change the underlying generated routes, by all means shoot.I''m not complaining that I have a way to make configuration easier or that routes.rb is not clean enough. What I''m complaining about *is* the underlying routes (spec. their names). In the example, I''m complaining about house_ - as in house_walls_path, house_windows_path, house_doors_path. In my controllers and templates I type that stuff out *so* much more often than *damage_path yet :damages is the only route that actually needs disambiguation. And I spend a lot less time configuring my routes.rb than I do coding controllers and templates so any routes.rb syntactic sugar like auto-name_prefix actually generates (and of course, maybe just for me) syntactic vinegar elsewhere. I either have to explicitly switch it off with name_prefix => nil for every route not needing disambiguation or I have to refer to (imho) overly-verbose route names. Either way though, given the constraints of limiting any solutions to ones that don''t change underlying routes, it looks like there''s not much I can offer. Thanks for taking the time to discuss this.> (P.S.: The tone of this exchange was much improved. Thank you for > paying attention to this.)And thank-you for giving me the chance to approach this issue with the correct attitude. Regards, Trevor -- -- Trevor Squires http://somethinglearned.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 -~----------~----~----~----~------~----~------~--~---
On 6/8/07, Tobias Lütke <tobias.luetke@gmail.com> wrote:> > > I''d apply a patch which would Dan''s style work.Didn''t realize my little thread would start so much discussion... That said, if I create a patch appending namespace to the front of the array is this still the approved direction? -- Josh Knowles joshknowles@gmail.com http://joshknowles.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 -~----------~----~----~----~------~----~------~--~---
On Jun 11, 12:51 pm, "Josh Knowles" <joshknow...@gmail.com> wrote:> Didn''t realize my little thread would start so much discussion... That said, > if I create a patch appending namespace to the front of the array is this > still the approved direction?I like it. Tobi mentioned doing just that when I first wrote the patch, but I wanted to get a basic solution out there and get some feedback going. -- -Jonathan. --~--~---------~--~----~------------~-------~--~----~ 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 6/11/07, Trevor Squires <trevor@protocool.com> wrote:> > > > With that in mind, consider this contrived example application: > > map.resources :houses do |house| > house.resources :walls, :has_many => :damages > house.resources :windows, :has_many => :damages > house.resources :doors, :has_many => :damages > house.resources :damages > end > > The :damages resource appears four times, touching every other > resource and the entire application seems to hinge on the concept > Damage. > > However, in terms of template and controller lines, Damage probably > (simplistically) only accounts for about 20% the application total.This is a bit off topic, but could anyone point me at some discussion about what the damages controller would look like in this situation. How much, and what code goes into determining what objects are to be setup? For example. I have a situation where I have :books, :has_many => :clips /books/1/clips This is fine, I can deal with this, but I would also like another part where I can look into others books /public/username/books/1/clips But I don''t really know what the controller should look like to set this up. Any links would be great. Cheers --~--~---------~--~----~------------~-------~--~----~ 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 6/8/07, Tobias Lütke <tobias.luetke@gmail.com> wrote:> > > I''d apply a patch which would Dan''s style work. > > Please do investigate :)http://dev.rubyonrails.org/ticket/8640 -- Josh Knowles joshknowles@gmail.com http://joshknowles.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 -~----------~----~----~----~------~----~------~--~---
On 6/12/07, Daniel N <has.sox@gmail.com> wrote:> This is a bit off topic, but could anyone point me at some discussion about > what the damages controller would look like in this situation. How much, > and what code goes into determining what objects are to be setup?Daniel, you''re right in that it''s slightly off-topic and probably a question better suited to the rubyonrails list (or IRC). That said, you''ve used my example to frame the question so I should probably give *some* sort of response. Ultimately, the best advice I can give you is: solve the problem in front of you in a way that doesn''t offend your taste and style. Here''s what I mean: Personally I like everything to be skinny (not just controllers) so I tend to have a lot of small and focussed objects that do only one job (but well, I hope). I also favor named-route url helpers over generic "give me a url for these args, I have no idea what they are" because it''s more expressive to me. I don''t automatically create top-level resources that mirror my nested ones - the idea being expressed has to actually exist (in a business sense) before it gets a url. And finally, I find first-pass generalizations are often wrong. As in "hey, X is the same as Y" almost always turns into "well, they''re *nearly* the same, I''ll just add a few conditionals" which eventually becomes "oh, I forgot about these cases, I have to add more conditionals". After years of doing this I''ve realized that developers are very quick to refactor from the specific to the general, but are often reluctant to refactor in the opposite direction (google for "fearofaddingclasses" for related discussions). So given that entire tug-of-war of my taste and style, the first thing I (often) reach for is "a specific controller for each route". I use a combination of inheritance, mixins and view re-use to avoid repetition. Once I have all the specifics nailed I check to make sure that my strategy isn''t getting in the way. If it is, then it''s a pretty simple matter to pull everything into a single controller to see how that looks. You''ll get completely different answers from other developers depending on their taste and style. Ask the question on the rails list to get more answers and take them out for a test-drive (thankfully we''re not pouring concrete here). HTH, Trevor -- -- Trevor Squires http://somethinglearned.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 -~----------~----~----~----~------~----~------~--~---
On 6/14/07, Trevor Squires <trevor@protocool.com> wrote:> > > On 6/12/07, Daniel N <has.sox@gmail.com> wrote: > > This is a bit off topic, but could anyone point me at some discussion > about > > what the damages controller would look like in this situation. How > much, > > and what code goes into determining what objects are to be setup? > > Daniel, > > you''re right in that it''s slightly off-topic and probably a question > better suited to the rubyonrails list (or IRC). That said, you''ve > used my example to frame the question so I should probably give *some* > sort of response. > > Ultimately, the best advice I can give you is: solve the problem in > front of you in a way that doesn''t offend your taste and style. > Here''s what I mean: > > Personally I like everything to be skinny (not just controllers) so I > tend to have a lot of small and focussed objects that do only one job > (but well, I hope). > > I also favor named-route url helpers over generic "give me a url for > these args, I have no idea what they are" because it''s more expressive > to me. > > I don''t automatically create top-level resources that mirror my nested > ones - the idea being expressed has to actually exist (in a business > sense) before it gets a url. > > And finally, I find first-pass generalizations are often wrong. As in > "hey, X is the same as Y" almost always turns into "well, they''re > *nearly* the same, I''ll just add a few conditionals" which eventually > becomes "oh, I forgot about these cases, I have to add more > conditionals". After years of doing this I''ve realized that > developers are very quick to refactor from the specific to the > general, but are often reluctant to refactor in the opposite > direction (google for "fearofaddingclasses" for related discussions). > > So given that entire tug-of-war of my taste and style, the first thing > I (often) reach for is "a specific controller for each route". I use > a combination of inheritance, mixins and view re-use to avoid > repetition. Once I have all the specifics nailed I check to make sure > that my strategy isn''t getting in the way. If it is, then it''s a > pretty simple matter to pull everything into a single controller to > see how that looks. > > You''ll get completely different answers from other developers > depending on their taste and style. Ask the question on the rails > list to get more answers and take them out for a test-drive > (thankfully we''re not pouring concrete here). > > HTH, > Trevor > > -- > -- > Trevor Squires > http://somethinglearned.comThanx Trevor. I didn''t even realise that this wasn''t the rails list. Forgot to look. Thankyou for your response. It''s defintely thought provoking for me. I''ll ask on the rails list to see if there is some kind of general consensus. Cheers Daniel --~--~---------~--~----~------------~-------~--~----~ 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 6/8/07, Tobias Lütke <tobias.luetke@gmail.com> wrote:> > > > > > I''d apply a patch which would Dan''s style work. > > > > Please do investigate :) > > > > http://dev.rubyonrails.org/ticket/8640 >All this lively conversation has distracted us from the original intent of this thread, which is getting namespace support into polymorphic urls. Please take a look at the submitted patch and let me know if there are any changes requested. -- Josh Knowles joshknowles@gmail.com http://joshknowles.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 -~----------~----~----~----~------~----~------~--~---
I''ve put in some bug fixes and improvements to polymorphic routes, which all should integrate fine with the above namespaced poly routes patch (any conflicts should be trivial to resolve.) 1. added poly_url and poly_path method aliases for polymorphic_url and polymorphic_path, including action_ prefixed methods (new_poly_url, edit_poly_url, formatted_poly_url). Much easier to type this shorter form. http://dev.rubyonrails.org/ticket/8725 2. fixed polymorphic_path so that it accepts an options hash like polymorphic_url -- necessary when you need to feed in an action, e.g. polymorphic_path(@article, :action => ''new'') http://dev.rubyonrails.org/ticket/8720 3. fixed polymorphic_url so that it generates :action => ''new'' routes correctly with an array, e.g., calls the method "article_new_comment_url" instead of "new_article_comment_url" http://dev.rubyonrails.org/ticket/8719 4. Added handling of nil parent objects in an array argument to polymorphic url -- so, polymorphic_url([@parent, @child]) generates an url with the parent (/parents/1/children/5) unless @parent is nil, in which case it just generates the route for the child (/children/5). As a result, you can build views that handle any nesting situation without adding conditional logic -- <%= link_to @person.name, [@company, @person] %> can generate both "/companies/1/people/5" and "/ people/5", depending upon if @company is set in the controller or not. http://dev.rubyonrails.org/ticket/8705 --~--~---------~--~----~------------~-------~--~----~ 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 really hate calling polymorphic_path directly. I really love what it does for me behind the scenes but I think named routes are much more descriptive. IMHO, polymorphic_path and polymorphic_url should go protected from direct calls. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
If you''ve named your instance variables descriptively, the polymorphic_url syntax is descriptive -- it shows the objects that appear in the url, and the order in which they appear: polymorphic_url [@company, @person] On Jun 22, 2:18 pm, Josh Peek <joshp...@gmail.com> wrote:> I really hate calling polymorphic_path directly. I really love what it > does for me behind the scenes but I think named routes are much more > descriptive. IMHO, polymorphic_path and polymorphic_url should go > protected from direct calls.--~--~---------~--~----~------------~-------~--~----~ 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 Jun 22, 3:18 pm, Josh Peek <joshp...@gmail.com> wrote:> IMHO, polymorphic_path and polymorphic_url should go > protected from direct calls.I agree. DHH said earlier that he thought url_for should never be called explicitly; I won''t go that far but I do think that polymorphic_url should stay behind the scenes. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Currently, polymorphic_url can be called behind-the-scenes like this: <%= link_to @person.name, [@company, @person] %> which generates http://www.example.com/companies/1/people/5 But if you want to create a link to /companies/1/people/new, / companies/1/people/5/edit, /companies/1/people.atom, etc., you need to call polymorphic_url (specifically, new_polymorphic_url, edit_polymorphic_url and formatted_polymorphic_url) -- example: <%= link_to ''New Person'', new_polymorphic_url [@company, @person] %> (...although currently, new_polymorphic_url fails with multiple arguments because polymorphic_url doesn''t call the correct named route; I''ve fixed this here: http://dev.rubyonrails.org/ticket/8719 ) The real gain for me is, when you''ve got a view that supports scoping of the resource by different parents, you can avoid putting in logic to build links appropriately, and just do: <%= link_to ''New Person'', new_polymorphic_url [@parent, @person] %> ... and the link will either be to /categories/1/people/new or / companies/19/people/new, depending upon if @parent is set to a Category or Company. And with this patch -- http://dev.rubyonrails.org/ticket/8705 -- if @parent is nil, you''ll just get /people/new This seems useful -- link_to can accommodate any nesting situation without wrapping it up in a custom helper, just so that the correct named route can be called. On Jun 22, 3:31 pm, Jonathan Vaught <jonathan.vau...@gmail.com> wrote:> On Jun 22, 3:18 pm, Josh Peek <joshp...@gmail.com> wrote: > > > IMHO, polymorphic_path and polymorphic_url should go > > protected from direct calls. > > I agree. DHH said earlier that he thought url_for should never be > called explicitly; I won''t go that far but I do think that > polymorphic_url should stay behind the scenes.--~--~---------~--~----~------------~-------~--~----~ 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 try to avoid the complex nested routing situations that you''ve described. link_to ''New Person'', company_new_person_path(@company) already works great for me. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
> <%= link_to ''New Person'', new_polymorphic_url [@company, @person] %>But here you know you have a company already. I don''t really see the utility of extending those cases unless there are common use cases where you *don''t* know what the first part of the url is. -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
The use case where you wouldn''t know the first part of the url would be: <%= link_to ''New Person'', new_polymorphic_url [@parent, @person] %> ...where @parent could be an instance of Company, and instance of Category, or nil. @parent would be set in the controller, based upon whether :company_id or :category_id were in the params (this technique is detailed in this post: http://revolutiononrails.blogspot.com/2007/05/drying-up-polymorphic-controllers.html ) Depending upon the value of @parent, the outputted href would be one of the following: /people/new /categories/5/people/new /companies/12/people/new So instead of doing conditional logic to decide whether to call new_person_url, category_new_person_url(@category), or company_new_person_url(@company), I''m just calling new_polymorphic_url, and leveraging the logic built in to that. On Jun 22, 7:46 pm, "Michael Koziarski" <mich...@koziarski.com> wrote:> > <%= link_to ''New Person'', new_polymorphic_url [@company, @person] %> > > But here you know you have a company already. I don''t really see the > utility of extending those cases unless there are common use cases > where you *don''t* know what the first part of the url is. > > -- > Cheers > > Koz--~--~---------~--~----~------------~-------~--~----~ 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 6/16/07, Josh Knowles <joshknowles@gmail.com> wrote:> > > > <http://dev.rubyonrails.org/ticket/8640>All this lively conversation has > > distracted us from the original intent of this thread, which is getting > > namespace support into polymorphic urls. Please take a look at the > > submitted patch and let me know if there are any changes requested. > > > >One last request for someone from core to look at this patch: http://dev.rubyonrails.org/ticket/8640 and then I''ll shut up. If this isn''t something appropriate for core just give me a heads up and I''ll extract into a plugin. -- Josh Knowles joshknowles@gmail.com http://joshknowles.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 -~----------~----~----~----~------~----~------~--~---
> One last request for someone from core to look at this patch: > http://dev.rubyonrails.org/ticket/8640 and then I''ll shut > up. > > If this isn''t something appropriate for core just give me a heads up and > I''ll extract into a plugin.I think it looks fine, it covers the simple case of [:admin, @customer] which works for me. If tobi has no objections, it looks good to go. -- Cheers Koz --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---