On Tue, 2005-03-29 at 20:53 -0600, Heath Borders wrote:
We would still need a separate flag in the component, this would just require more advanced logic in the tag.
Yes, but I think this is more logic to use the encode attribute than to add one or 2 new ones.
Again, I'm still afraid that it doesn't really count as encoding, since a <br /> != '\n' according to the HTML spec. it would have to be something like &newline;
As for <br/> != '\n' maybe but I have no better proposal.
The code will use the HTMLEncoder.encode that has an encodeNewline and an encodeSubsequentBlanksToNbsp parameters.
So this detail should be dealt with in the HTMLEncoder anyway.
What do you mean about the &newline; ?
To me this is MathML, not HTML.
Just to summarize, my proposal is to add a third possible value to the x:outputText' escape attribute that would be complete.
When escape="complete", the x:outputText uses the HTMLEncoder to encode new lines and subsequent blanks.
Does someone has a better proposal or objects this ?
Thanks,
Sylvain.
On Tue, 29 Mar 2005 22:27:21 -0400, Sylvain Vieujot <[EMAIL PROTECTED]> wrote: > While coding this, I find that the idea to have an encodeNewLines attribute > isn't really 100% satisfying, as to really reproduce the text submitted via > a textarea (or even a standard text), with the formating, we also need to > encode the subsequent blanks. > 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. > > > > > > > > > > > >
