Conditional layouts ignore default application wide layout

I think the reason for this would be that the "_action_has_layout?" method returns false if you use the "layout" method to set the layout with conditions and the action called is not in the list.
As a workaround I would pass the layout to render in the index action like so:

{{{ def index

# ...
render :layout => 'full_width'

end }}}

this way the index action will render full_width and all other actions will default to the application layout or whatever other layout you have specified.

Which Rails version?

OK, I will try to do it tomorrow.

I have been looking at this problem and my conclusion is that the problem in here is that one controller only can stores one layout definition:

# layout.rb

def layout(template_name, conditions = {}, auto = false)
  add_layout_conditions(conditions)
  write_inheritable_attribute(:layout, template_name)
  write_inheritable_attribute(:auto_layout, auto)
end

So each time we call to layout method the layout attribute will be reset to the new value even if this layout is intended to be used only on one action.

Another problem in here is that we can't make a definition like this:

class HasTwoOwnLayoutWithConditionsController < LayoutTest
  layout 'layout_wadus', :only => 'wadus'
  layout 'layout_churro', :only => 'churro'
end

Because the second call to layout method will delete what is defined on the first one, so this is not gonna work:

def test_layout_with_two_layouts_with_conditions_definided
  @controller = HasTwoOwnLayoutWithConditionsController.new
  get :churro
  assert_equal 'layouts/layout_churro', @response.layout
  
  get :wadus
  assert_equal 'layouts/layout_wadus', @response.layout
  
  get :hello
  assert_equal 'layouts/layout_test', @response.layout
end

If we add to the fixtures/layout_tests all the layouts and views needed only the first assertion will work because it is defined on the last call to the layout method.

What I think could be a solution is to change the layout.rb class so on every call to layout method a new layout definition will be stored but without delete the already stored layouts, so what we will have will be an Stack of layouts and to figure out what layout has to be used on a particular action of a particular controller we will have to check all the Stack from top to bottom.

The problem is double because the layout definition is not stored on only one attribute, remember the method layout on the class layout.rb pasted above.

I can try to implement a solution but I need to receive feedback of my conclusions since this could be a very big change on layout implementation.

Regards.

f.

Fernando has a good point. Maintaing the stack seems like a good idea. However if the stack has options like only and except then figuring out the correct layout might take time and there will be performance hit.

The other approach would be to resolve which layout will be applied to which method at boot time. The issue in this case would be if someone adds a new method to a controller dynamically.

I haven't looked at rails3 but I do remember that in one of the speeches Yehuda mentioned that to make filters run faster in rails3 , he takes that second approach mentioned above. I might be wrong but he resolves what all filters will be applied to a method at boot time. Not sure how and if he handles if a method is added dynamically.

Either way the solution would require some structural change. And as Fernando said a high level guideline from the core team would be a help.

Hey guys, I made other ticket with a more limited scope, but I agree with Fernando we should have more flexibility and even ability to add 2+ layout declarations.

https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets...