I ended up with an if/else statement to generate my text_field
differently based on the boolean test for “disabledness”.
It kind of makes sense to me that doing <%= … <%= … %> …%> might
cause problems.
However, is there an alternative way to achieve this behavior, when you
want to use <%= %> to generate dynamic attributes within the call to a
helper method?
How I intended it was that you call it exactly like text_field but
specify
any additional options as a hash. These options are merged with the
existing
options hash you¹ve provided in the original call. The reason for the
two
options hashes is that the function signature is what you¹re familiar
with.
But, now that you mention it, the code should probably be:
How does this work? Would each hash element get looked at to see if it
was a code block and then, if so, the yield happens?
So options would have keys value, id, maxlength, and then the last key
would be a code block containing a hash, the yield would happen and when
complete, you end up with another hash element (with whatever value got
determined in the block)?
Just trying to make sure I get it.
Interesting. I agree - not sure if this helps anything :).
%>) %>
However, is there an alternative way to achieve this behavior,
when you
want to use <%= %> to generate dynamic attributes within the call
to a
helper method?
Thanks,
Wes
On Jul 6, 2006, at 4:35 PM, s.ross wrote:
sometest}} %>
I don’t know if this makes things better or worse
What’s wrong with: (note the trailing . on the 2nd line
No need to get complicated about it. You’re already doing Ruby in
the <%= … %> so just add the code you need.
Now, if you were using this all over the place, then a helper might
be useful. In particular, the HTML ‘disabled’ attribute really needs
to be ‘disabled=“disabled”’ if you want to be XHTML 1.0. If your
only conditional was to set a field disabled or not, I’d make the
helper know specifically about the :disabled key and set the options
hash given to text_field similarly to how I’ve done it above.