+3 patch needs a better name for an options key passed to map.resources

http://dev.rubyonrails.org/ticket/10578

This is a +3 patch that would add an option :path_substitute
(originally :path_replace) to map.resources.

This helps in creating customised URL's irrespective of what the
resources were called.

For e.g. if I want to keep my resources in English, but the URLs to
talk spanish, then:

  map.resources :products, :path_substitute=>'productos' do |product|
    product.resources :product_reviews, :path_substitute =>
'comentarios'
  end
  map.resources :tutors, :path_substitute=>'tutores' do |tutor|
    product.resources :tutor_reviews, :path_substitute=> 'comentarios'
  end

These will yield paths like the following:

  productos/:product_id/comentarios
  tutores/:tutor_id/comentarios

People liked the patch but were wondering what the key should be
called as?

Suggestions on trac were:

:path_replace (original patch)
:path_substitute (current patch)
:path (apparently would confuse)

Any suggestions welcome. Thanks.

We’re changing the name of the resource in the URL, right? So why not call the option:

:path_name

The symbol suggests: “change the name of this resource as it appears in the URL path”.

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.

map.resources :tutors, :opaque_name => :tutores

tutors_path() => /tutores

Regards,

Trevor

Why not just

   map.resources :tutors, :as => :tutores

?

The id in a nested route is still tutors_id isn't it, internally there are only tutors right?

-- fxn

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.

Regards,

Trevor

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”:

  1. not transparent or translucent; impenetrable to light; not allowing light to pass through.
  2. not transmitting radiation, sound, heat, etc.
  3. not shining or bright; dark; dull.
  4. hard to understand; not clear or lucid; obscure: The problem remains opaque despite explanations.
  5. 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.

Mislav,

I used ‘opaque’ as related to “not transparent”.

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” :slight_smile:

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).

It's not even the path, it's the portion of the path for this segment
of the declaration

map.resources :people, :other_name=>'folks' do |folks|
  folks.resources :comments
end

all I can see is :name_of_path_segment or path_segment_name...

So I just want to finish by saying (/me bangs his fist on the table) that
this bike shed *must* be blue![*]

My shed is pink[1] therefore this one must be too!

all I can see is :name_of_path_segment or path_segment_name…

+1 for “path_segment”.

My shed is pink[1] therefore this one must be too!

Guys, guys! The shed should be #E0115F, and that’s final.
=)

I feel :path_segment is not quite intuitive for a non-native English
speaker (the likely user of the patch).

anyway if I can have 2 votes
+1 :path
+1 :path_segment

Can't the same thing be accomplished with:

map.resources :productos, :controller => :products

James

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.

-- fxn

I'd just suggest letting :other_name (or whatever the correct term
shakes out to be) take an array

map.resources :people, :other_names => ['folks', 'gentes','personoj']
do |person|
person.resources :comments
end

This pattern can support multiple aliasing in segment paths for people
who need to translate urls into more than one alternate language.

-Trek

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).

-- fxn

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

http://en.wikipedia.org/wiki/URI_scheme

defines it as segment, so perhaps we should call it
just :path_segment.

I shall give it another day for feedback before I update the patch.
Thank you all

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.

  • Mislav