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