Item1186: EditRowPlugin: textarea newlines are not saved with whitespace around br
Priority: Normal
Current State: Closed
Released In: n/a
Target Release: n/a
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