Re: [Rails-core] bug in new map.resources
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 PM, David Heinemeier Hansson wrote: When do you feel that you need postbacks? In some sense, I'm seeingthe 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 likea good fit? I'm starting to think that explicitly ignoring them withmap.resources is a feature. Eh, postbacks aren't a big deal. The amount of code is similar either way. I just thought it was neat to be able to continue to support that functionality. If moving away from that style is an explicit goal of restful routes, then I'm cool with it. And since (as Rick reminds us) we have the :any method option, one can still do postbacks if it's really needed.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 difference so if I'm a lone voice on this I'll shut up, but I did want to at least put it forth as an option.--Josh Susserhttp://blog.hasmanythrough.comI'll toss in a +1 for easy postback support. I personally prefer having the consolidated methods.--Benjamin Curtishttp://www.bencurtis.com/http://www.tesly.com/ -- Collaborative test case managementhttp://www.agilewebdevelopment.com/ -- Resources for the Rails communityHeh, sorry about the formatting of that last email. Mail.app me.___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] bug in new map.resources
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
(hash) will lose all but one of the actions that have the same method.
flip_keys_and_values({ :reply = :get, :create_reply = :post, :spawn
= :post, :split = :post })
# = { :get = :reply, :post = :create_reply }
(YMMV for the particular :post action retained depending on the
randomish hash ordering.)
I don't think you'll be able to get flip_keys_and_values to do what
you want and return a hash. The old way of inverting a hash into an
array of arrays seemed to work fine.
--
Josh Susser
http://blog.hasmanythrough.com
Could you by chance get a failing test? The SR tests are in
actionpack/test/controller/resources_test.rb. I've fixed 2 slight
bugs that I was seeing in my apps and I think I have one or two more
still.
--
Rick Olson
http://techno-weenie.net
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] bug in new map.resources
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.resources :articles, :member = { :reply = :get,
:create_reply = :post, :spawn
= :post, :split = :post }
- or -
map.resources :articles, :member = { :get = :reply,
:post =
[:create_reply, :spawn, :split] }
The second form seems simpler to me, and it's what the code needs
internally already so no fancy flipping required. It also has the
advantage that you could create routes that support multiple http
methods, if that doesn't break something else:
map.resources :articles, :member = { :get = [:reply],
:post =
[:reply, :spawn, :split] }
That gets us back to being able to do post-back actions, which is a
nice pattern and I think makes controllers simpler. Don't know what
it would do to the routing internals for using http methods though.
--josh
On Jul 31, 2006, at 1:27 PM, Josh Susser 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(hash) will lose all but one of the actions
that have the same method.
flip_keys_and_values({ :reply = :get, :create_reply
= :post, :spawn = :post, :split = :post })
# = { :get = :reply, :post = :create_reply }
(YMMV for the particular :post action retained depending on the
randomish hash ordering.)
I don't think you'll be able to get flip_keys_and_values to do what
you want and return a hash. The old way of inverting a hash into
an array of arrays seemed to work fine.
--
Josh Susser
http://blog.hasmanythrough.com
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] bug in new map.resources
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 different :method
conditions). Not sure if that is going to cause a problem in the
route code somewhere.
map.resources :comments, :member = { :get = :reply, :post =
[:reply, :spawn, :split] }
j
--
Josh Susser
http://blog.hasmanythrough.com
flipped_action_options.diff
Description: Binary data
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: Re: [Rails-core] bug in new map.resources
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 different :method conditions). Not sure if that is going to cause a problem in the route code somewhere. Hi Josh, 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 think that explicitly ignoring them with map.resources is a feature. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: Re: [Rails-core] bug in new map.resources
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 difference so if I'm a lone voice on this I'll shut up, but I did want to at least put it forth as an option. I actually consider the verbosity a feature in this case. If you're writing so many additional methods that the repetition is beginning to bug you, you should revisit your intentions. You're probably not being as RESTful as you could be. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework ___ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Re: [Rails-core] bug in new map.resources
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 (at least when doing restful routes).
It's not a huge difference so if I'm a lone voice on this I'll shut
up, but I did want to at least put it forth as an option.
I actually consider the verbosity a feature in this case. If you're
writing so many additional methods that the repetition is beginning to
bug you, you should revisit your intentions. You're probably not being
as RESTful as you could be.
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 is all that, you shouldn't need to
rely on syntactic vinegar to force people to do it the right way.
Now, if you were to say that organizing the actions hash as {:action
= method, ...} is desirable because it guarantees an action only is
used once, then sure, that makes sense. Either way, I can get behind
it.
--
Josh Susser
http://blog.hasmanythrough.com
___
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
