That's a good point. These conversions could be done just with a converter.
On Wed, 30 Mar 2005 10:58:56 -0800, Korhonen, Kalle <[EMAIL PROTECTED]> wrote: > Sylvain, > > If you are going that route, I'd suggest "all" instead of "complete". And > agree with Heath about <br /> != '\n', but &newline. That said, couldn't you > make a converter to deal with these character conversions? I'm not sure if > the converter is invoked before initializing the value, so you might need to > call the converter explicitly in your code for the initial value, but a good > thing is the converter would also deal with user typed values. > > Kalle > > ________________________________ > From: Sylvain Vieujot [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 29, 2005 6:27 PM > To: MyFaces Development > Subject: Re: HTMLEcoder and \n > > > 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. > > > > > > > > > > > > -- -Heath Borders-Wing [EMAIL PROTECTED]
