It's a bite overkill to have 2 attributes for this, as the real intent is (IMO) to either reproduce to formating entered by the user, or to ignore it.
So, I have another suggestion : to add another value to the escape attribute : complete
So escape could be "false", "true" (standard) or "complete", to fully encode all relevant characters (including subsequent blanks, tabs & \n).
Would this make you upgrade your votes to +0.95 ??
Sylvain.
On Tue, 2005-03-29 at 12:44 -0400, Sylvain Vieujot wrote:
A simple case where I think it makes sens (that's when I hit this problem) is when you input text via a text area, and then wants to use the user's text as a comment on a page.
Then, the formating is lost. In fact, it's in the source, but that doesn't make much difference to the user.
That's why I thought the spec would have made this encoding the standard feature.
Anyway, thanks for your feedback.
I'll add this attribute, and hope it'll be the standard way in future specs.
Sylvain.
On Tue, 2005-03-29 at 09:59 -0600, Heath Borders wrote:It seems like you juts shouldn't be worrying about '\n's in your output. That's basically presentation logic, and you needn't worry about it. That's what makes me a little hesistant about adding this. However, doing it as you said is easy to turn off, so +0.9 On Tue, 29 Mar 2005 17:51:20 +0200, Manfred Geiler <[EMAIL PROTECTED]> wrote: > +0.9 > > > On Tue, 29 Mar 2005 11:28:09 -0400, Sylvain Vieujot <[EMAIL PROTECTED]> wrote: > > Indeed, as Oliver said, the spec says : > > "all angle brackets should be converted to the ampersand xx semicolon > > syntax when rendering the value of the "value" attribute as the value of the > > component." > > And doesn't mention anything about \n. > > This is a bit sad, but that's the situation. > > > > I think the simplest fix would be to add an encodeNewline (defaults false) > > attribute to x:outputText. > > > > I don't know about the pluggable interface, but it looks a bite complex to > > me for such a small requirement. > > > > Does everyone agree that I add this new attribute ? > > > > Thanks, > > > > Sylvain. > > > > > > On Tue, 2005-03-29 at 08:52 -0600, Heath Borders wrote: > > For something like <h:outputText /> its really not hard to write your own > > renderer, or to write a custom renderer. We could always apply logic like > > you're asking to an <x:outputText /> tag/renderer. On Tue, 29 Mar 2005 > > 08:59:27 +0200, Mathias Broekelmann <[EMAIL PROTECTED]> wrote: > Hi, > > > > wouldn´t it be nice to have a pluggable interface for those issues? > > > Setting escape to false requires the user to encode all characters to > > > valid html/xml. We also have a requirement to print <sup> or <sub> > markups > > which replaces special chars in the strings. That interface > could be > > retrieved and registered through an Application sub class. > > Mathias > > > > Oliver Rossmueller wrote: > > Sylvain Vieujot wrote: > > > >> By default, > > HTMLEncoder.encode( txt ) doesn't encode \n to <br/>. > >> So, > > <h:outputText> doesn't encode the new lines either. > >> > >> Is this > > expected ? > >> > >> My guess would be that by default, the new lines should > > be encoded. > > > > > > Sylvain, > > > > to not encode newline characters is > > expected behaviour, the spec does > > not require h:outputText to encode > > newlines. There is only the > > requirement that > > > > "characters that > > are sensitive in HTML and XML markup must be escaped" > > > > when the > > encode flag is set to true (which is the default). So if you > > need <br /> > > for newlines in your text you have to do it on your own (and > > don't > > forget to set encode="false" for the h:outputText in this case > > otherwise > > the <br/>s will end up on the user's screen). > > > > Oliver > > > >> > >> > > Sylvain. > > > > > > > > > > >
<<attachment: smiley-4.png>>
