> * 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 [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
-~----------~----~----~----~------~----~------~--~---
