Use params, not @params
Posted by marcel April 25, 2006 @ 04:30 AM
I still frequently see people in the #rubyonrails channel using @params in their code. For a while now @params has been deprecated in favor of simply params. For those who just skim these blog posts:
Use params, not @params
Why? When you use the params method, it allows for the implementation details of the parameter hash to be changed without breaking existing code. If the implementation of params changed you wouldn’t have to change your code at all because the single point of access for the parameters would just remain the params method. So, the details of what is happening behind the scenes don’t matter. If, though, you use the @params instance variable directly, you’ve broken encapsulation and consequently the ability for the implementation to be easily modified. Methods can be refactored, but instance variables can’t. Today the params method just wraps the @params instance variable, so still using @params works, but that’s not guaranteed to always remain the case.
Same goes for request, response, session, headers, template, cookies and flash.
Basically, a good rule of thumb here is don’t use an instance variable in your controller or view unless you created that instance variable.
Even the old @content_for_layout in the layout is deprecated in favor of just using yield in its place. Also content_for('some_fragment') is now accessed with yield :some_fragment rather than @content_for_some_fragment.
This was news for me. The “still” in your first sentence seems to imply that I ought to know this already. Where is information like this officially published?
And I’m not sure from your explanation how I should use yield for the layout. Where can I find more information on this? Only the ”@content_for_layout” approach is present in the API docs.
You say:
“Basically, a good rule of thumb here is don’t use an instance variable in your controller or view unless you created that instance variable.”
Wouldn’t it make more sense to say:
“Basically, a good rule of thumb here is to never use an instance variable in your controller. Use getter methods created in your controller instead.”
As to my mind this will protect yourself from the same types of changes that you described may happen to @params, thus maintaining encapsulation.
Or is there a case where you see that it’s actually beneficial to use in instance variable directly in your view?
Yeah, this is also kind of new. And there is a lot of “wrong”/depreciated code out there. so please post more often about these kind of changes, because otherwise updates will become more and more difficult in the future.
I’m glad to see that there’s ‘official’ word on the
@params/paramsissue, although I do feel that the promotion ofyieldand the deprecation ofcontent_for_*moves away from DSL into the realms of Rubyisms, a consequence of which might result in a steeper learning curve.yieldis a very nice hack for the layout.And: We’re all used to get our Rails documentation from everywhere but api.rubyonrails.org, don’t we? ;) Rails is not only the best, but also the most mystic framework in the world.
For instance, there:
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/154903
Shame… I kinda like
params, etc. It gives them a visual indication that they're "special", both because of theand because of the syntax highlighting. “params” just doesn’t look as cool as ”@params”, but I’ll get used to it…Sigh… should have previewed. Should have read:
Shame… I kinda like
@params, etc. It gives them a visual indication that they’re “special”, both because of the@and because of the syntax highlighting.paramsjust doesn’t look as cool as@params, but I’ll get used to it…On the yield issue…
I like doing things like this:Using
yield :scriptwould require me to re-capture the output in order to check for its presence.Is there a best practice for this pattern using the preferred
yieldsyntax?Well, altough I never used @params I always used @content_for_<your variable>. the yield thing is news to me. Maybe we can revise the api site to reflect this changes. http://api.rubyonrails.org/classes/ActionView/Helpers/CaptureHelper.html#M000528
Well, altough I never used @params I always used @content_for_<your variable>. the yield thing is news to me. Maybe we can revise the api site to reflect this changes. http://api.rubyonrails.org/classes/ActionView/Helpers/CaptureHelper.html#M000528
Once we get this cleared up, lets update the documentation and the rails books. More often then not, I use them as reference points, ruby newbie that I am
Actually, as much as I think that this change in convention wasn’t handled well, I think it’s probably a good idea, and not only because of what it does for future-proofing. “yield” isn’t terribly difficult to remember, but gives an important insight as to how @content_for_layout actually worked.
For Ruby newbies: skip to the section on “blocks and iterators” to understand the yield method.
http://ruby-doc.org/docs/ProgrammingRuby/html/tut_containers.html
In Rails 1.1.2, doesn’t scaffold generate @content_for_layout in the layouts? I’ve heard of these best practices, but I think a lot of newcomers to Rails would be confused that this is good convention if the framework generates structure that tells them otherwise.
Is there a plan to change this soon?
Rails is a great framework – the more I find out about it, the more I like it. The difficulty is finding out about it. You really have to mine to get the gems. Books like “Agile Development on Rails”, “Rails Recipies”, etc. are great for getting started, but what is needed is a more comprehensive documentation of all of Rails’ intricacies. Right now we have the api rdoc (which is okay but not updated and sometimes unclear), the Rails wiki (one of the best places to look for help), and the mailing list (tons of good stuff but hard to find). A team of people documenting the Rails language in all of its glory by gardening the Rails wiki so that it is as accurate and complete as possible and thus becomes the definitive pit-stop for all things Rails—could, in my opinion, help further Rails usage almost more than anything else. I realize I’m offering an idea rather than being part of the solution, but I don’t have enough deep understanding of Rails myself to edit documentation—I’m still very much in the learning stage.
I think this is bang on! I love any changes that relieve the burden on my short-term memory buffer (the one that’s installed in my brain).
Using simple ‘params’ reduces the noise for me.
As for ‘yield’, it’s beautiful, since it condenses longer ‘content_for’, and eliminates the underscore.
These may seem like insignificant little things, but they are actually huge. It’s what makes Ruby so special—this painstaking attention to how humans work, think and play.
Just noticed the changeset for the @content_for_layout to yield as of this morning. Thanks guys!
Seth, here’s how you check for @content_for_script using yield:
That will only capture the content once. The only objection I could see with this is the creation of variables in the view, but that’s pretty trivial in my opinion.
Where and when was that mentioned?!?
And how is yield used instead? Where’s the docs?
Joe: Just use <%= yield %>
Ok that should have had the percents in there, sorry
zerohalo@gmail.com: Agreed.
The only thing holding back Rails right now (well, maybe not holding back but rather, slowing down an already speeding train!) is lack of clear, concise documentation.
IMO, PHP does this the best, and has almost since the start. User-contributed comments, easy searching, and clear, relevant examples will be the trifecta that brings Rails into the “well-documentated” camp.
Now, who will step up to the plate?
I should add that clear documentation is especially relevant given the rapid rate Rails is progressing. Things that were kosher 6 months or even 1 month ago are suddenly taboo.
And, the very beginning should be stuff like, “where to use :symbols in place of ‘single quotes’ or “double quotes” and how to use @instance variables, and so on.
You say to use the params function, because what’s necessary for the implementation in the future may change. Why doesn’t the same stand for content_for? Using yield is not abstracted in any fashion. Shouldn’t there be a content_for(string) method that wraps yield in case something changes with that implementation?
We’d be happy to get some help getting better documentation out there. Please do find ways to help. Cleaning up the wiki, writing documentation patches, doing articles. Jump on board!
I just replaced <%= @content_for_layout %> with <%= yield %> in my code and it worked fine. Note that <% yield %> does not produce the desired result. You need the <%= %> tag
In my former favorite language, using a deprecated construct generated a warning. That might be useful here, but I’m a Ruby newbie and have no idea how this might be implemented.
+1 to Steve V (#25). Yield doesn’t automatically understandable, not like content_for. Less beauty, then.
<= yield > or <%= yield %> ?
This is exactly the kind of things difficult to understand for a newbie. I agree with others claiming that books like “Agile Development on Rails�, “Rails Recipies�, etc. need an update to reflect these changes.
Sorry, I understood: the from removed the % percent symbol so we should use <%= yield %>
damn! I meant the form, not the from!
Yay! Finally, someone is complaining about this. Been bothing me for a while.
How can I update http://ap.rubyonrails.org/classes/ActionController/Layout/ClassMethods.html ?
All the related documentation was updated before this post was made. The documentation at api.rubyonrails.org is updated when a new release is made. For those using edge rails, you see the updated documentation here: http://caboo.se/doc/
Oh… Just one of those things I really wish I knew a while ago. Always wondered about this. Guess that’s why I should’ve really learned ruby before diving into rails :) /agree with a lot of posters here though. We really do need a “best practices” cheat sheet kind of thing. I don’t feel I have the “oomph” to write it, though.
All the related documentation was updated before this post was made.
Wouldn’t that be nice. In fact, vendor/rails/actionpack/README.html still recommends @content_for_layout and @params.
For real Ruby/Rails newbies, will anyone please explains how the params (without
@) works. I understand@params is an attribute of the controller, but what is params? A named parameter? Because I thought instance attributes always begin with "@”, so params/request/etc looks like a local variable.Kevin Marsh’s comment about the PHP site is absolutely correct. I believe that the PHP documentation is just incredible. A similar site for both Ruby and Rails would lead to an explosion of developers. Whether you have an interest in PHP or not, if you have never visited the site, then you should definitely do so.
(PHP Manual)
“All the related documentation was updated before this post was made. The documentation at api.rubyonrails.org is updated when a new release is made.”
I agree with Marc Baumbach – for those of us just starting out (and getting our info from, for instance, Agile 1) changes to the API mean little when the generators are generating deprecated code. Some of us aren’t far enough up to speed for reading the raw API, and the learning curve will be even steeper since we’re establishing patterns of usage that have become outdated.