Item1186: EditRowPlugin: textarea newlines are not saved with whitespace around br

Please see Item1017 EditTablePlugin again cannot save textareas with formatting because of wrong handling of new lines

EditRowPlugin suffers from the same problem.

When fixing make sure not to repeat an old ETP bug. When saving the plugin should leave ONE space before and after the <br />. If there already is a space avoid adding more at each save

-- KennethLavrsen - 02 Mar 2009

Based on what I read in Item1017, I think you maybe misunderstand how it is supposed to work. The textarea edit in the table editor was never intended to be WYSIWYG. It is a literal representation of what is typed, with the one caveat that BR is used in place of newlines in the output because the output is used in a Foswiki table, which does not tolerate embedded newlines. The table editor isn't doing anything wrong; the bug is in the core rendering code, which is not equivalencing <br /> and \n for rendering thinks like embedded links.

I think it would be a mistake to try and "fix" this in the table editing plugins; the bug is in the core, and fixing it in the plugins will just create a gopher problem as the "special" handling of BR causes other bugs. I think we should raise a bug against the core.

If you want WYSIWYG in edit fields, then we need to work out how to use TinyMCE in the table editor.

-- CrawfordCurrie - 09 Mar 2009

I do not think you yet understand at all what 1017 is about. I have never said anything about WYSIWYG.

People edit the tables using the EditTablePlugin or EditRowPlugin and normal people with normal brains have every reason to expect normal TML and html links to work.

If you want to change the core code to interpret a <br /> before it renders the code may make sense. In fact it would also fix the problem that you can no longer use bullets and tables in formfields. Another place where normal people with normal brains would expect TML to work.

But I would be careful making such a core change in a patch release. Who knows how many that counts on a html br to prevent rendering.

But for ETP and ERP I see every day people adding URLs and bold and italic to table cells that end up not being rendered and they give me "the look" when I say they have to add a lame silly space in front of the text to get a URL rendered. There is no problem with normal tables. People that manually write a html br knows they need to leave white space. But a textarea field in ETP/ERP just does not make this step logical because people do not write the html br. It is added by ETP/ERP. And when we add the br tag we should let humans be humans and take care of making these new lines work like new lines with a space around the html br like you would have done if you had typed | hello <br /> http://dr.dk |

Again - I see this problem day after day after day. And it is highly annoying. Today someone used an ETP to record the answers to questions raised at a review. The questions were types in a table cell. And he wanted to put his answer in italic one line below. Result. His italic is not rendered italic but shown with the underscores. Yesterday it was someone typing html links in a quality plan topic. Links did not work. Again because of this bug. It is so dammed annoying for the users.

-- KennethLavrsen - 09 Mar 2009

Hmm, it appears someone else added this br support, which is why i didn;t recognise what you were referring to.

Having tracked it down, I added the spaces in question.

-- CrawfordCurrie - 10 Sep 2010

Fixed

-- CrawfordCurrie - 14 Feb 2011