This project is archived and is in readonly mode.

#4328 ✓resolved
Andrew White

Missing support for actions on a new resource in new routing DSL

Reported by Andrew White | April 5th, 2010 @ 07:09 AM | in 3.0.2

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.

Comments and changes to this ticket

  • José Valim

    José Valim June 7th, 2010 @ 10:11 AM

    • Milestone cleared.
    • State changed from “new” to “open”
    • Assigned user changed from “Joshua Peek” 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 White

    Andrew White June 7th, 2010 @ 11:29 AM

    I thought it did but there's an issue with the name prefix. I'll fix it and post a new patch later today.

  • DHH

    DHH June 7th, 2010 @ 11:10 PM

    Not 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

    José Valim June 7th, 2010 @ 11:13 PM

    Andrew, could you then update the patch based on DHH's feedback? Thanks!

  • José Valim

    José Valim June 7th, 2010 @ 11:32 PM

    • 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

    Andrew White June 8th, 2010 @ 06:07 AM

    Okay here's the updated patch. The member block for singletons is now optional, :on => :new works and tests pass.

  • Repository

    Repository June 8th, 2010 @ 08:17 AM

    • State changed from “open” to “resolved”

    (from [4740fbac85d6190cccd244f943d7a578c607b806]) Add support for actions on a new resource to the new routing DSL [#4328 state:resolved]

    Signed-off-by: José Valim jose.valim@gmail.com
    http://github.com/rails/rails/commit/4740fbac85d6190cccd244f943d7a5...

  • Niels Meersschaert

    Niels Meersschaert October 8th, 2010 @ 09:19 PM

    • 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

    Andrew White October 8th, 2010 @ 09:30 PM

    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

    Niels Meersschaert October 9th, 2010 @ 12:10 AM

    Here is a sample route we are attempting to use in Rails 3.0
    resources :accounts do
    collection do

    get :outlook
    post :invoice_all
    

    end member do

    post :invoice
    get :manage_invoices
    post :regenerate_invoice
    

    end new do

    post :load_highrise_details
    post :get_highrise_contacts
    post :search_highrise_companies
    

    end 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

    Niels Meersschaert October 9th, 2010 @ 12:14 AM

    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")

  • Andrew White

    Andrew White October 9th, 2010 @ 06:00 AM

    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.

  • Jeremy Kemper

    Jeremy Kemper October 15th, 2010 @ 11:01 PM

    • Milestone set to 3.0.2

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

<h2 style="font-size: 14px">Tickets have moved to Github</h2>

The new ticket tracker is available at <a href="https://github.com/rails/rails/issues">https://github.com/rails/rails/issues</a>

Referenced by

Pages