Locals in render partials

In render partials can we pass arrays like this

a=[1,2,3]
b=[5,6,7]
c << a << b

render :partial=>’’,:locals=>{:c=>c}

Nike M. wrote:

In render partials can we pass arrays like this

a=[1,2,3]
b=[5,6,7]
c << a << b

render :partial=>’’,:locals=>{:c=>c}

Yes. Write a functional test on the behavior of the page with the
partial, and
you should be able to detect the effects of :c inside there.

BTW, I always name variables passed in :locals like :@c, so they appear
as @c
inside. This makes them easier to test for nil, to mean “unassigned”.

(Do the latest versions of Rails and Ruby support that?)

I tried your suggestion of passing locals as :@var on ruby 1.8.6 and
rails 2.2.2 and it doesn’t seem to work

Felix wrote:

I tried your suggestion of passing locals as :@var on ruby 1.8.6 and
rails 2.2.2 and it doesn’t seem to work

Tx…

Not to hijack the thread (I’m unsure if Nike M.'s question feels
answered
yet), but we are having a major problem with…

  • too many tests
  • too many render :partial and render :inline calls
  • too many @ variables magically passed without :locals

Apparently we reach a threshold where the magic stops working, and our
most
important @ variables disappear. This leads to a cascade of incorrect
test
failures on missing nils. (The infamous “whiny nil” takes over.)

So if I fix that using :locals =>{ :@q => @q } in every render call,
then I
impair our project for upgrading to 2.2.2…

Elaborate sigh…

The problem with :locals => { :q => @q } is you can’t say ‘if q’ inside
the
partial to detect if the local is set. You can say ‘if @q’, because you
rely on
Ruby to provide a nil for decorated variables that don’t exist yet…

I seem to recall you can’t do ‘if defined? q’, either. Maybe.

This means the final recourse is too ugly for Rails: :locals =>{ :things
=>{ :q
=> @q } }. Now the partial can use ‘if things[:q]’…


Phlip