[Rails-core] Re: +3 patch needs a better name for an options key passed to map.resources

On Jan 27, 2008 3:30 AM, Michael Koziarski <[EMAIL PROTECTED]> 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. =) --~--~-~-

[Rails-core] Re: +3 patch needs a better name for an options key passed to map.resources

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

[Rails-core] Re: association preloading problems.

On Jan 27, 2008 1:39 AM, Frederick Cheung <[EMAIL PROTECTED]> wrote: > > - first off there are some patches on > http://dev.rubyonrails.org/attachment/ticket/9640 > that look sane to me (and maybe have slipped under the radar because > they weren't in their own ticket). It's probably best if t

[Rails-core] Re: About the RubyOnRails build xxxx failed

> When does an error reported from continuous integration classify as > irrelevant? There's obviously something wrong with it as it reports failures that I don't see on either of my development systems. However, we definitely have one error which david deliberately added a few weeks ago (the NoM

[Rails-core] Re: +3 patch needs a better name for an options key passed to map.resources

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

[Rails-core] Re: +3 patch needs a better name for an options key passed to map.resources

On Jan 26, 2008 8:01 PM, Xavier Noria <[EMAIL PROTECTED]> 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 o

[Rails-core] Re: +3 patch needs a better name for an options key passed to map.resources

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

[Rails-core] Re: +3 patch needs a better name for an options key passed to map.resources

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, Tre

[Rails-core] Re: +3 patch needs a better name for an options key passed to map.resources

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

[Rails-core] Re: About the RubyOnRails build xxxx failed

http://groups.google.com/group/rubyonrails-core/browse_thread/thread/709b561c028a8f5e http://groups.google.com/group/rubyonrails-core/browse_thread/thread/d2bf59cd861b Or just have a look at any recent emails from cc.rb On Jan 26, 2008 5:11 PM, Mislav Marohnić <[EMAIL PROTECTED]> wrote: > On

[Rails-core] Re: About the RubyOnRails build xxxx failed

On Jan 26, 2008 1:12 PM, Pratik <[EMAIL PROTECTED]> wrote: > > On Jan 26, 2008 12:07 PM, Jean-François Trân <[EMAIL PROTECTED]> > wrote: > > - Yes it's useful > > Except, someone needs to kick CC.rb. It is showing completely irrelevant > errors. When does an error reported from continuous integr

[Rails-core] Re: +3 patch needs a better name for an options key passed to map.resources

On Jan 26, 2008 12:56 PM, blj <[EMAIL PROTECTED]> 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 cha

[Rails-core] association preloading problems.

- first off there are some patches on http://dev.rubyonrails.org/attachment/ticket/9640 that look sane to me (and maybe have slipped under the radar because they weren't in their own ticket). Secondly it has been very rightly pointed out that the include_eager_conditions? and include_eager

[Rails-core] Re: About the RubyOnRails build xxxx failed

On Jan 26, 2008 12:07 PM, Jean-François Trân <[EMAIL PROTECTED]> wrote: > - Yes it's useful Except, someone needs to kick CC.rb. It is showing completely irrelevant errors. -- Cheers! - Pratik http://m.onkey.org --~--~-~--~~~---~--~~ You received this message bec

[Rails-core] Re: Preload Associations - bug

On 26 Jan 2008, at 03:11, Peter wrote: > > parents will return [nil, # person_id: 10001, position_id: 4, void_cheque: 0, hired_on: nil, > terminated_on: nil>] > > The issue is when the preload of the association takes place, one of > the models returns nothing, the first element, and this creates

[Rails-core] Re: About the RubyOnRails build xxxx failed

2008/1/26, blj <[EMAIL PROTECTED]>: > > This group is inundated with the automated cruise control posts of > > RubyOnRails build failed > > This comes across as a spam to me. Is this helping any one at all? - Yes it's useful - No, it isn't spam - Feel free to put a filter in your mail user a

[Rails-core] About the RubyOnRails build xxxx failed

This group is inundated with the automated cruise control posts of RubyOnRails build failed This comes across as a spam to me. Is this helping any one at all? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Rub

[Rails-core] +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 U