ryanb
The blueprint system is broken for complex forms
I have a form that is semantically tabular. Therefore it is laid out in a <table> element.
My fields_for then outputs some table rows. Unfortunately, it turns out jQuery's $ function cannot handle arbitrary HTML.
Example : $('<div><tr><td>foobar</td></tr></div>') gives [<div>foobar</div>]
Therefore, jQuery doesn't understand my blueprint, and drops the <tr> and <td> elements, ruining my document.
I believe the proper fix would be to actually move away from having the blueprint as an attribute, but instead use an actual DOM node.
I think it's possible to use $(elem).before(content) instead of $(content).insertBefore(elem)`. Could you please confirm this?
I'm not sure how that would really fix things: do you really think that would change the way the string is parsed as HTML? Per jQuery's documentation, this behavior is inherited from the browser's innerHTML parsing…
I just found a workaround: passing a :wrapper => false to fields_for remove the wrapping div, and has the nice side-effect of letting WebKit parse the HTML properly. It's definitely not a real fix though :-)
Damnit. Nope, I hadn't seen it, and was just working my way figuring out the exact same workarounds…
Thanks a lot for pointing me to it!
Still, I believe the issue remain. And the JavaScript workaround at the end does work, but IMHO it would be better to be able to specify an arbitrary insertion zone in link_to_add.
Thanks a lot though!
It'd be great to modify default insertion behavior to use data attribute on link_to_add that is specifying an insertion zone. But in this case we should think about different possible options and try to handle them.
Personally I'm okay with the current ability to override insertion method and make it application specific. But I appreciate somebody working on making default behavior customized easier. I'll try to help this person with guides and suggestions.