What I meant by &newline; was that if such a thing existed in HTML, then I would have no problem including this with the encode, but since it doesn't, it just feels a little fishy.
You're right, however that we do need something like what you're saying, but since we'll need a totally different property on the component anyways, we might as well have that on the tag. So, I'd rather see something like "convertLineBreaks" or something on the tag. On Wed, 30 Mar 2005 08:34:57 -0400, Sylvain Vieujot <[EMAIL PROTECTED]> wrote: > Inline. > > 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. > > > > > > > > > > > > -- -Heath Borders-Wing [EMAIL PROTECTED]
