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([EMAIL PROTECTED], @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 [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
