One of my plugins has this feature and I call it :opaque_name. I chose ‘opaque’ because to me, that’s exactly what it is - a name that doesn’t let you “see through” to the underlying resource naming structure.
Well, this isn’t my patch so I can’t speak for the author, but when I added that feature to my plugin I did consider :as - but I discarded it because it didn’t seem communicate exactly what would happen.
If you didn’t know about the feature and you saw:
map.resources :tutors, :as => :tutores
You could reasonably assume tutores_path() was valid just as much as you could assume tutors_path() was valid.
map.resources :tutors, :opaque_name => :tutores
indicates (to me, anyhow) that something is unusual with :tutores - it sticks out like a sore thumb, prompting you to discover what that means.
It looks too much like polymorphic stuff in Rails. And it does not imply that only paths are affected.
And Trevor, I don’t like “opaque_name”, either. I don’t see how opacity makes sense to you in this context. Here is what dictionary.com says about “opaque”:
not transparent or translucent; impenetrable to light; not allowing light to pass through.
not transmitting radiation, sound, heat, etc.
not shining or bright; dark; dull.
hard to understand; not clear or lucid; obscure: The problem remains opaque despite explanations.
dull, stupid, or unintelligent.
Personally, I’m slightly surprised that “path_name” didn’t cross anyone’s mind on both discussions (Trac and ML) when it is the most simple, self-descriptive and consistent.
I was frustrated that map.resources enforced such a tight coupling with param names and generated url helpers that I found myself wishing: “why isn’t there an easy way to make the URLs more opaque?”.
Perhaps being able to “see through the url” to the underlying param names and url helpers is a poor metaphor - but that’s just what speaks to me.
As for path_name, I disagree. It’s not the name of the path, it is the path (if you interpret path as something that is prefixed with path_prefix).
So I just want to finish by saying (/me bangs his fist on the table) that this bike shed must be blue![*]
Regards,
Trevor
[*] if you don’t get that, google for “bikeshedding”
That gives new_productos_path, :producto_id in nested routes, .... It is assumed in this thread you don't want that. You only want to get fake URLs so to speak.
If there's one choice products_path generates /productos always.
Having an array implies being able to select its elements in named routes. I don't know whether such generality responds to a real need and it's worth the trouble, but in any case I'd like to point out it is not enough, it would need perhaps a hash so that you can say projects_path(:es).
I am not sure how this is supposed to work. Is it multiple path to the
same resource? what happens to named uri helpers as Xavier Noria
asked? Anyway, it is achievable by having more than one resource for
the same controller though, if required.
I would suggest :name_in_path as the name for the key.
I think the meaning of
map.resources :products, :other_name=>‘productos’ do
is not inferred directly, but
map.resources :products, :name_in_path=>‘productos’ do
is (almost) self-explanatory
After :path_segment got a +1 from Koz, myself, Balaji and Jerome, this patch gets applied by Jeremy using :as. So much for community input =P
http://dev.rubyonrails.org/changeset/8785
I’m just kidding – if it had to be any other name among the suggested, I’d choose :as. I’m glad that this is finally in; now with the help of some 301s I’ll translate some URLs of my app in Croatian. Thanks, Balaji.
