This project is archived and is in readonly mode.
Missing support for actions on a new resource in new routing DSL
The deprecated mapper supported adding resource actions that operated on a new resource, e.g:
# /posts/new/preview
map.resources :posts, :new => { :preview => :post }
The attached patch adds support for this to the new routing DSL. e.g:
resources :posts do
new do
post :preview
end
end
To add this behaviour to singleton resources I've had to make a breaking DSL change. Rather than directly specifying member actions inside the resource block, they need to be nested inside a member block. e.g:
resource :account do
get :info # Now raises an exception
end
resource :account do
member do
get :info
end
new do
post :preview
end
end
I did look at still allowing member routes on singleton resources to be specified directly inside the resource block but I personally felt it was better to have a consistent DSL.
-
José Valim- Milestone cleared.
- State changed from new to open
- Assigned user changed from josh to José Valim
I put it under my radar. If we are going to do it, it should be before the RC. Your patch also ensures the following syntax work?
get :action, :on => :new -
Andrew WhiteI thought it did but there's an issue with the name prefix. I'll fix it and post a new patch later today.
-
DHHNot a fan of the required member block for singletons. It's fine to have new be in a block without having members do.
-
José Valim
Andrew, could you then update the patch based on DHH's feedback? Thanks!
-
José Valim
- Milestone cleared.
Since we are not deprecating the API, it is not a blocker for RC. That said, I'm changing the milestone.
-
Andrew White
Okay here's the updated patch. The member block for singletons is now optional, :on => :new works and tests pass.
-
Repository- State changed from open to resolved
(from [4740fbac85d6190cccd244f943d7a578c607b806]) Add support for actions on a new resource to the new routing DSL [#4328 Missing support for actions on a new resource in new routing DSL state:resolved]
Signed-off-by: José Valim jose.valim@gmail.com
http://github.com/rails/rails/commit/4740fbac85d6190cccd244f943d7a5... -
Niels Meersschaert- Importance changed from to Medium
This commit doesn't appear to be in 3.0 final release. Is it slated to be released at some time? I am running into problems as a result of the broken new resource support without this patch.
-
Andrew White
The mapper was refactored heavily between this commit and the final release but actions on a new resource are definitely in there - can you post a sample route where you think it is failing.
-
Niels Meersschaert
Here is a sample route we are attempting to use in Rails 3.0
resources :accounts do
collection doget :outlook post :invoice_allend member do
post :invoice get :manage_invoices post :regenerate_invoiceend new do
post :load_highrise_details post :get_highrise_contacts post :search_highrise_companiesend end
Running rake routes, these properly show the routes as expected. However, when actually trying to run those calls, it shows in the logfile as parameters {id => "new"} for any of our new resource routes. We have other similar routes where we support the same action both for new & members & then check if id param was passed to determine if we do Object.find(id) or Object.new. That worked perfectly in Rails 2.x, but has been a problem in our Rails 3 migration. We've resorted to using named routes for each new resource call to workaround this behavior, but obviously, it isn't an ideal solution.
-
Niels Meersschaert
Here's the route snippet as an attached file due to formatting fun.
Additionally due to the id => new, our current code gets a RecordNotFound due to running Object.find("new")
-
routes.txt
363 Bytes
-
-
Andrew White
You need to move your new actions ahead of your member actions - the routes are being matched in the order in which they are declared.
-
