This project is archived and is in readonly mode.

#2162 ✓wontfix

layout chaining

Reported by JasonKing | March 7th, 2009 @ 07:55 AM | in 2.x

This began as a mistake in (the Layouts and Rendering in Rails guide)[] where the author expected two layout calls in a controller to have their behaviour chained together.

I thought that made a lot of sense, so instead of a patch for the docs, I've attached a patch for action_controller/layout.rb with accompanying tests.

Comments and changes to this ticket

  • José Valim

    José Valim March 7th, 2009 @ 09:42 AM

    This won't break current applications?

    For example, if I do in my ApplicationController:

    class ApplicationController < ActionController::Base

    layout 'default'


    And then:

    class AdminController < ApplicationController

    layout 'admin'


    Since you are using inheritable array I'm almost sure that this will nest the layout, right?

    And I can't see also any use case for this feature.

  • JasonKing

    JasonKing March 7th, 2009 @ 11:46 AM

    That use case doesn't change. The last layout called is the one that takes precedence, and because the last layout called has no conditions then it will be used for all actions on AdminController.

    Here's a use case showing the effect of this patch:

    class FoosController < ApplicationController
      layout 'products'
      layout 'login', :only => 'login'
      layout 'forum', :only => 'forum'

    Right now this will just cause confusion because actually both :only conditions are stored, but only the 'forum' layout will ever be rendered.

    With my chaining patch, the behaviour will be far more as one would expect, with each condition only applying to corresponding template, and chaining back through the layouts until it finds one that applies for the called action.

  • José Valim

    José Valim March 7th, 2009 @ 02:21 PM

    I think now I got it. The name totally confused me as I thought that you would nest one layout inside the other (which makes no sense). Maybe you could change the title? :)

  • Ryan Angilly

    Ryan Angilly March 7th, 2009 @ 05:32 PM

    I haven't ran this patch, but +1 for concept

  • Jeremy Olliver

    Jeremy Olliver March 8th, 2009 @ 07:33 AM

    Sounds like a good idea to me too.

    The patch doesn't apply cleanly to the current master though, could you update the patch with the latest master?

  • JasonKing

    JasonKing March 11th, 2009 @ 05:51 PM

    Email notifications aren't working for me - sorry for the delay :(

    Just rebased, should be good now.

  • Matt Jones

    Matt Jones March 12th, 2009 @ 07:09 AM

    As this has been punted to the next release, I've updated the guide to correctly reflect the current behavior.

  • CancelProfileIsBroken

    CancelProfileIsBroken May 16th, 2009 @ 05:21 PM

    • Assigned user set to “Yehuda Katz (wycats)”

    Any thoughts on how this will behave in 3.0? We shouldn't make this change on 2.x unless 3.0 will behave the same way.

  • Yehuda Katz (wycats)

    Yehuda Katz (wycats) May 16th, 2009 @ 05:46 PM

    I really don't like this idea at all. It looks like another example of moving app-specific logic with very uncommon use-cases into a core location in the framework. Every such innocuous change adds more complexity to the overall system, including parts of Rails that are only tangentially related.

    Why could this not be achieved with an in-app helper that captured the content with its appropriate layout and then using that capture in the layout. I'd personally be much more amenable to a helper that made that sort of thing easier than in adding more complexity to the already non-trivial layout system.

  • CancelProfileIsBroken

    CancelProfileIsBroken May 16th, 2009 @ 05:51 PM

    • State changed from “new” to “wontfix”

    The helper solution seems more likely to work cleanly in both 2.x and 3.0 if you want to pursue it.

  • JasonKing

    JasonKing May 16th, 2009 @ 11:23 PM

    Have you guys seen my second comment in this ticket?

    Where multiple layout statements with conditions will have their conditions combined, but the template itself is overwritten.

    There are two options that I can see to solve this, one was the layout chaining idea that I was investigating in this patch, the other is to ensure that previous conditions are cleared/overwritten when processing the layout call.

    This issue shouldn't be closed until one of those is done.

  • bingbing

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=""></a>