On 08/17/2012 01:22 PM, Petr Blaho wrote:
On Friday, August 17, 2012 10:52:46 AM Jirka Tomasek wrote:
On 08/16/2012 05:05 PM, Matt Wagner wrote:
Hi folks,
I've noticed that we've been objecting to patches using instance
variables to pass information to views, so I went to see our coding
guidelines page[1] to read about why.
It makes very clear that it's bad, but it doesn't really explain the
right way. I'd hoped that the Coding Guidelines page would be more of a
guide on how to do things the right way.
I've really only found one blog post[2] that addresses the issue, and it
doesn't really give a great example. It still uses an instance variable
in the controller, but inside of a view it passes it as a local
variable. It's more specific, sure, but it's not abundantly clear how
that actually makes anything better, or why an instance variable from
the controller to the view is okay but a view to a partial is not okay.
Can someone with a more concrete understanding of the right way update
the wiki page, or send me some pointers so I can do so? I'd love for the
page to show the right way, maybe an example of rewriting the "bad way"
into the right way, rather than just giving a stern warning that it's
bad.
-- Matt
[1]
https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Coding_Guidelines
[2]
http://rails-bestpractices.com/posts/27-replace-instance-variable-with-local-variable
I don't like the sentence "Don't use it for passing variables to view.
Never." which is actually one of the first things that any Rails book
teaches you. I agree that we should try to reduce using instance
variables in controllers where possible to avoid cluttering controllers
with them.
The blog post you sent points out the reusability of partials so passing
the variables as locals helps avoid requiring use of eg. @post in all
partials instances. Imho it depends on the desired use of the partial.
We have discussed with Imre the alternative way to pass variables from
controller's action to view. It can be done similar way as with partials:
...someactioncode...
render :action => :index, :locals => {:post => post}
end
Yes, this is the way I use them.
One reason is to be clear what variables a view needs.
Another one is that in this way I use no instance variables in views.
And why I am trying to avoid them in views? Because of implicit nil value
when instance variable is not defined before. That brings problems when
you rely on value of that variable. Something changes in controller or model
and suddenly your view do not work and you have to find out why.
I prefer explicit code when variable can be nil or undefined - we can use
local_assigns[:variable_name] in view.
Partials thing Jirka mentioned - in past I often refactored views to partials
and sometimes I used partials common for more resources. In that cases
I hated how views dictated controllers what instance variables they had to
define.
I like to see when views are more detached from controllers.
We have to use instance variables when we use filters in controllers
to manipulate some data in memory. Even in this case I would like
to see solution not using before filters at all (for memory data manipulation)
and I would use simple method call with return value.
But that is not the "Rails way" and in fact it is part of another discussion.
These are quite reasonable arguments but personally I never felt it that
problematic to avoid using them. Actually for me this is a neat feature
of Ruby rather than an issue.
I think we should keep our coding standards in align with the standards
of the Ruby and the Rails community. As Jirka wrote, there is no book on
Rails that uses this approach, none of them matches with our coding
guideline.
As Matt linked from Rails Best Practices, they only recommend it for
partials, not for all views as we specify. Our strict approach may
frighten off future contributors, so I vote for not creating stricter
coding standards than reasonable and let developers choose which
approach they prefer.
Imre
but I have never seen this used anywhere in controller and I assume this
is not the "Rails way".
Jirka
