Feature Proposal: VarENCODE with an adicional parameter type to convert newlines into HTML

Motivation

Forms with textareas allow newlines to be entered.

If the contents of those form fields are to be displayed inside a EDITTABLE, the newlines need to be escaped to HTML or just removed, so that the table lines don't get broken

Description and Documentation

Create a new paramter type on VarENCODE that allows to encode the newlines in a string into an HTML break tag.

Examples

%EDITTABLE{format="|label,0,Info|label,0,Val|"}%
| *Info* | *Val* |
| *Description* | %ENCODE{"%FORMFIELD{"Description"}%" type="newlines" }% | 

Impact

Implementation

-- Contributors: JoseVenceslau - 09 Oct 2008

Discussion

Small and compatible change, I support it.

-- PeterThoeny - 12 Oct 2008

Good idea, though I'd personally prefer type="$n" (less to type, and consistency with format). Most "odd" characters (such as vertical bar |) are already supported by ENCODE{type="entity". Since combining entity and $n is going to be a very common case, especially in tables, it would be good if you could support type="entity+$n" as well as type="$n" - otherwise the user is stuck having to do two ENCODEs. (For full clarity ENCODE{type="x+y+z" should be defined as applying the encodings in that order i.e. x then y then z, in case encoding x generates characters that are encoded by y or z. We need to keep ENCODE as generic as possible, because we need to be able to use it when generating other outputs, not just HTML)

-- CrawfordCurrie - 12 Oct 2008

We have feature requests for a FORMAT parameter that may overlap proposal above: AddTruncateVAR and ExtractAndCentralizeFormattingRefactor.

-- ArthurClemens - 12 Oct 2008

I don't think either of those links covers what Jose is proposing. AddTruncateVAR describes a useful string operation that may require a format parameter, and ExtractAndCentralizeFormattingRefactor hints at a way to normalise a number of string operations into a single variable. Consider how you would process a search result that returns a string containing both vertical bars and newlines to get what I mean.

-- CrawfordCurrie - 13 Oct 2008

I'm not partial to newline name and I'm quite partial to the less to write argument, so feel free to change the name ;^)

$n implies (at least to me) that it should be treated as a variable and, although it conforms to SEARCH format, it is a bit at odds with the rest of the ENCODE parameters.

The patch, as it is, is just a couple of lines. Supporting x+y+z is more complex and may have different outcomes depending on the order (escaping newlines first and entity after is not the same as escaping entity first and newlines later) which makes ENCODE type more complex to understand and takes some of the elegance out of it, IMHO.

-- JoseVenceslau - 14 Oct 2008

Ping! Anyone following up on this?

-- PeterThoeny - 2010-06-23