Wtf?? No instance vars!

[rapha]

Up until now I was using the xhtml_careful branch. Then I wanted Rails 1.2 goodness (a.k.a. form_tag with blocks). It seemed the trunk was more up to serving my needs (#43). I switched. Now stuff breaks.

Controller:

@column_headers = [['name', 2], ['account'], ['postcode'], ['city']]

View:

@column_headers = @helpers.controller::assigns['column_headers']

Without the line in the view, I get a nil object where truly I did not expect one :-(

Help?

[rapha]

Interestingly, flash[:whatever] works, but params[:whatever] doesn't and needs the same hack as above.

[rapha]

Just set up a small rails application just for testing. The problem still appears.

table {
  for product in @products
    tr {
      for column in Product.content_columns
        td product.send(column.name)
      end
    }
  end
}

does not work, but

table {
  for product in @helpers.controller.assigns['products']
    tr {
      for column in Product.content_columns
        td product.send(column.name)
      end
    }
  end
}

does.

No idea yet what the problem is. There's a guy in #rubyonrails who claims it works for him...

[rapha]

More bad news, when POSTing, params[:whatever] doesn't arrive in the controller. Haven't found a way around that at all yet (@params[:whatever] is also empty).

[tec]

Replying to rapha:

Interestingly, flash[:whatever] works, but params[:whatever] doesn't and needs the same hack as above.

params is a controller attribute, and shouldn't need to be accessed from the view. If you need to, you can use @helpers.controller.send(:params). The reason flash works is because there is a shortcut for it in markaby/rails.rb.

[tec]

Replying to rapha:

No idea yet what the problem is.

Should work: for product in products

[tsg21]

instance vars of the form:

  for product in @products

were removed in revision 87, I think becuase it was deemed that they are ugly.

I'm not entirely convinced by this myself - to me having an @ prefix is a nice way to differentiate the xhtml building code from the variables you are inserting. It also broke quite a lot of my existing code.

Seems to me that people should be able to decide for themselves whether or not to use those @ prefixes. Or is it plain old bad ruby?

[tec]

Replying to tsg21:

I think becuase it was deemed that they are ugly.

Not so much that using @products is ugly, but that (IMO) copying local assigns into Builder instance variables is "not good design".

I'm not entirely convinced by this myself - to me having an @ prefix is a nice way to differentiate the xhtml building code from the variables you are inserting.

Good point, I can appreciate that. But it might just be because everyone's been conditioned into using ivars by Rails. Liquid for example, doesn't have them.

It also broke quite a lot of my existing code.

Sorry! The new code hasn't been included in a "released" version of Markaby, but anyone on Rails is forced to use it - Piston looks useful for avoiding breakages.

Seems to me that people should be able to decide for themselves whether or not to use those @ prefixes.

Yes, choice is good. I've put everything back in [100].