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
On 7/31/06, Josh Susser <josh@hasmanythrough.com> 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.comCould 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
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
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 looking at your first post. +1
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
_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core
On 7/31/06, Josh Susser <josh@hasmanythrough.com> 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 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] } >We discussed this some more and decided against it. Having postbacks goes against what simply_restful is doing. Keep in mind, nothing simply_restful does is impossible to do with routing. The resources macro is designed to reward those using conventions. If you do need to a reply action on both get and post, you can try this: map.connect ''/comments/:id;reply'', :conditions => { :method => :post } map.resources :comments, :member => { :reply => :get } -- Rick Olson http://techno-weenie.net
> 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
> > 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://techno-weenie.net
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 think that explicitly ignoring them with > map.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 Susser http://blog.hasmanythrough.com
> 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
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
-- Benjamin Curtis http://www.bencurtis.com/ http://www.tesly.com/ -- Collaborative test case management http://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 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. > > 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 Susser > http://blog.hasmanythrough.comI''ll toss in a +1 for easy postback support. I personally prefer having the consolidated methods. -- Benjamin Curtis http://www.bencurtis.com/ http://www.tesly.com/ -- Collaborative test case management http://www.agilewebdevelopment.com/ -- Resources for the Rails community _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
On Aug 1, 2006, at 5:49 AM, Benjamin Curtis wrote:> > -- > Benjamin Curtis > http://www.bencurtis.com/ > http://www.tesly.com/ -- Collaborative test case management > http://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 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. >> >> 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 Susser >> http://blog.hasmanythrough.com > > I''ll toss in a +1 for easy postback support. I personally prefer > having the consolidated methods. > > -- > Benjamin Curtis > http://www.bencurtis.com/ > http://www.tesly.com/ -- Collaborative test case management > http://www.agilewebdevelopment.com/ -- Resources for the Rails > community >Heh, 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
> 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.I do, actually. And I love the term syntactic vinegar. Consider it stolen ;) I think syntactic vinegar is one of the best ways to encourage people to do the right thing. You''re basically allowing them to do whatever they want, but if they''re cutting against the grain, they''ll have to suffer ugliness. This means that you can when you must, but won''t when it doesn''t matter. Ruby itself is built heavily upon syntactic vinegar in spots that you shouldn''t be fumbling with too much (like ObjectSpace). Syntactic vinegar. Love it. -- 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