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

[blj]

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.

[Mislav Marohnić]

On Jan 26, 2008 12:56 PM, blj <brag...@gmail.com> wrote:

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

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

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

[Trevor Squires]

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

--
--
Trevor Squires
http://somethinglearned.com

[Xavier Noria]

On Jan 26, 2008, at 7:55 PM, Trevor Squires wrote:

> 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

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

[Trevor Squires]

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

[Mislav Marohnić]

On Jan 26, 2008 8:01 PM, Xavier Noria <f...@hashref.com> wrote:

Why not just

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

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.

[Trevor Squires]

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" :-)

On 1/26/08, Mislav Marohnić <mislav....@gmail.com> wrote:

[Michael Koziarski]

> 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!

--
Cheers

Koz

[1] http://www.flickr.com/photos/koz/31291186/in/set-698503/

[Mislav Marohnić]

On Jan 27, 2008 3:30 AM, Michael Koziarski <mic...@koziarski.com> wrote:

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

[blj]

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

[James H.]

Can't the same thing be accomplished with:

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

James

[Xavier Noria]

On Jan 27, 2008, at 3:18 PM, James H. wrote:

> Can't the same thing be accomplished with:
>
> map.resources :productos, :controller => :products

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

[Trek Glowacki]

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

[Xavier Noria]

On Jan 27, 2008, at 4:41 PM, Trek Glowacki wrote:

> 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

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

[blj]

On Jan 27, 8:41 pm, Trek Glowacki <trek.glowa...@gmail.com> wrote:
> 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
>

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.

[Juanjo Bazán]

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

[blj]

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

[Mislav Marohnić]

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