Just checking... You think that code that is less readable and more
tedious to write is an advantage? I guess from the perspective of
macro-optimization vs micro-optimization I wouldn't argue with you,
but I think that's a hell of a way to encourage people to do the
right thing. If going restful
On Aug 1, 2006, at 5:49 AM, Benjamin Curtis wrote: --Benjamin Curtishttp://www.bencurtis.com/http://www.tesly.com/ -- Collaborative test case managementhttp://www.agilewebdevelopment.com/ -- Resources for the Rails community On Jul 31, 2006, at 9:33 PM, Josh Susser wrote:On Jul 31, 2006, at 8:33 P
--Benjamin Curtishttp://www.bencurtis.com/http://www.tesly.com/ -- Collaborative test case managementhttp://www.agilewebdevelopment.com/ -- Resources for the Rails community On Jul 31, 2006, at 9:33 PM, Josh Susser wrote:On Jul 31, 2006, at 8:33 PM, David Heinemeier Hansson wrote: When do you feel
On Jul 31, 2006, at 9:41 PM, David Heinemeier Hansson wrote:
Postbacks aside, I still think inverting the optional actions hashes
(key by method instead of action) is still a better way to go. It's
less to type, less to transform, and I tend to think of the actions
grouped by http method anyway
Postbacks aside, I still think inverting the optional actions hashes
(key by method instead of action) is still a better way to go. It's
less to type, less to transform, and I tend to think of the actions
grouped by http method anyway (at least when doing restful routes).
It's not a huge differen
On Jul 31, 2006, at 8:33 PM, David Heinemeier Hansson wrote:
When do you feel that you need postbacks? In some sense, I'm seeing
the use of a richer verb set as a way of rescuing us from postbacks.
Do you have a few examples in a REST-powered app where they feel like
a good fit? I'm starting to
> map.resources :comments, :member => { :get => :reply, :post =>
> [:reply, :spawn, :split] }
I totally forgot about this feature:
:member => { :reply => :any }
Look at line 151
http://dev.rubyonrails.org/browser/trunk/actionpack/lib/action_controller/resources.rb#L151
--
Rick Olson
http://t
Here's a patch that changes map.resources to use the "flipped" hashes
for optional actions. Tests pass for new arrangement. Looks like
postback actions seem to work again too, though the
#filtered_named_routes method in your routing_navigator only shows
one of the routes with the same name (but
On 7/31/06, Josh Susser <[EMAIL PROTECTED]> wrote:
Here's a patch that changes map.resources to use the "flipped" hashes
for optional actions. Tests pass for new arrangement. Looks like
postback actions seem to work again too, though the
#filtered_named_routes method in your routing_navigator o
Here's a patch that changes map.resources to use the "flipped" hashes
for optional actions. Tests pass for new arrangement. Looks like
postback actions seem to work again too, though the
#filtered_named_routes method in your routing_navigator only shows
one of the routes with the same nam
On 2006-07-31, at 19:07 , Josh Susser wrote:
and the flipped version is actually more compact to specify. For
example:
map.resources :articles, :member => { :get => :reply,
:post =>
[:create_reply, :spawn, :split] }
That's what I thought just by lo
In working out a fix for the flip_keys_and_values bug in
map.resources, I got to thinking that the current API for specifying
extra actions is backwards. The code doesn't use the un-flipped hash
at all, and the flipped version is actually more compact to specify.
For example:
map.resour
On 7/31/06, Josh Susser <[EMAIL PROTECTED]> wrote:
Since trac is still out to lunch...
It's great to see SimplyRestful at last being rolled into trunk. The
code refactoring looks nice, however there is a bug in handling extra
actions in the collection/member/new options. flip_keys_and_values
(
Since trac is still out to lunch...
It's great to see SimplyRestful at last being rolled into trunk. The
code refactoring looks nice, however there is a bug in handling extra
actions in the collection/member/new options. flip_keys_and_values
(hash) will lose all but one of the actions that
14 matches
Mail list logo
