#125 Dynamic Layouts

Great cast again, so helpful, i dont think i would have leant so much in the past year without your help.

Much appreciated!

Brilliant! Your timing couldn't have been better..

It is so cool to see how easy it is to get a significant feature into a Rails app. Thanks!

One question: what are the security issues involved with letting the user pick her own layout? It would be unfortunate if something like "../../../etc/" were allowed. Is it up to us to prevent this? I can't tell from the "layout" method itself.

@Jeremy, that's a good question, and I'm not sure if the layout method prevents this either. Even if it does I think it's best to ensure this in our application with a validation.

# blog.rb
validates_format_of :layout_name, :with => /^[a-z]+$/i

Wow, very handy. Thanks again Ryan!

Hi Ryan.

 I really love your screencasts - they've been very helpful to me, so thanks a lot for your effort!

 I must say though, I was disappointed to see how basic this episode was. I know, that not all your viewers are advanced, but this really wasn't very creative :/ No offense, but a beginner would've done this without much effort, or research..

 I'll be waiting impatiently for the next episode hoping it will be as exciting as some of your previous ones (the advanced forms come to mind :)

Cheers!

PS. Perhaps some of your viewers would be interested in hearing about the redhillonrails plugins (http://redhillonrails.org/) - I've been using Foreign Key Associations, Foreign Key Migrations, Redhillonrails Core, Schema Validations and Transactional Migrations ever since and they've saved me a LOT of time and effort, DRYing my code and ensuring that it works properly. The guys at Redhill have done a tremendous job and released the code for all of us to benefit from - big kudos to them!

Thanks, Ryan. For me, all your screencasts have been perfectly timed. And your casts always use the 'best practices' for smaller things (which others ignore sometimes) like the proxy.pac for the subdomain cast; using liquid (for security) for the templates; the active resource screencasts. I love each and every one of them and find them to be the best way to show my team how to do things the right way.

@AC, thanks for the feedback. I try to get variety in the episodes. Some will be basic, others advanced. While this episode doesn't show any new techniques, it combines several techniques shown in previous episodes which I think will be valuable to some. I have a few ideas for more advanced episodes in the near future, stay tuned. :)

This is exactly the kind of programming we'd want to avoid for thread safety reasons. Better way would be http://pastie.org/264443

@Pratik, thanks for the correction. I'll mention it in the show notes. Since Rails is becoming thread safe I have to pay more attention to this kind of thing!

The thread safe code now loads the layout for every action, not just show. Why not just leave the dynamic layout code in the blog_controller now? Anyway, with 2.2 approaching fast, there will be a lot of code needing modification to make it thread safe, maybe a screen cast about it?

@Jonathan, it will call set_layout for every action, but it checks for the existence of @current_blog which is only set for the show action. In a sense it's doing the same thing.

I haven't had a chance to fully test this yet, so I'll play around with it to make sure it works properly. But in theory it should.

I'm not sure what happens if you now call "layout" in another controller - does it override this :set_layout? Gotta try that.

Hi Ryan,

Great screencast. I'm just wondering what makes the original code NOT thread safe, and what makes the new code thread safe. That would be very helpful in writing better thread safe code.

Thanks,
Paul

@Paul, from my understanding, the layout is global state, and setting global state directly in a request is a bad thing to do since this is shared between threads. Setting it in one thread will effect another.

Someone please correct me if I'm wrong.

Nice screencast. But I was waiting all the time for one small note: Before rendering a different HTML layout, everyone should check, if they can modify the layout just by css. If your layout is from this century, that should be enough in 99% of the cases.

wow I was just learning about liquid last night. what an awesome coincidence you posted this episode this week. I love these screen casts. I always learn little tricks that I take with me everywhere.

About the custom layout rendering, an easier solution in this case is to use the render method setting the layout param. See it: http://pastie.org/266849

Ryan,
The comments above regarding thread safety remind me of an issue we've seen lately in various Rails projects. It might make a good screencast: the danger of cached classes in production environment (the default setting in new Rails projects) and application state work-arounds with code like 'User.current_user' or 'Project.current'. Imagine what happens when you forget to nullify that value after each controller action :)

Thanks, Ryan. For me, all your screencasts have been perfectly timed. And your casts always use the 'best practices' for smaller things (which others ignore sometimes) like the proxy.pac for the subdomain cast; using liquid (for security) for the templates; the active resource screencasts. I love each and every one of them and find them to be the best way to show my team how to do things the right way.

Can we specify a path to a layout? Instead of just the name of layout which is picked from ./views/layouts directory?

I am really interested in some ideas of creating themeing system in Rails. Any good pointers?

Can someone please explain why the original code is not thread save vs. pratik's code?

Big thanks @ Ryan for this nice episode again.

Its so nice and kindly learning rails with your screencasts :-)

I've copied this code for my Page model and carefully changed the variables etc however I'm receiving the following error: "Redirect Loop
Redirection limit for this URL exceeded. Unable to load the requested page. This may be caused by cookies that are blocked."

I'm passing an attribute called permalink in the load_page method though:
@current_page = Page.find_by_permalink(id)

Thanks,
- Ryan

Great screencast Ryan. Yet again, exactly what I was looking for. I have a question though; How would you go about caching something like this? I have just implemented this in a site which (I hope) will have quite high traffic, mainly db reads. I've used mongodb, so hopefully that will help.

hey Ryan, please make a new screencast about that.

Hey