Oic. Well, how about adding an attribute plainText="true" that causes plainText to look normal in html (i.e. space = " " and '\n' = "<br />")?
On Wed, 30 Mar 2005 10:51:36 -0400, Sylvain Vieujot <[EMAIL PROTECTED]> wrote: > The reason I moved away from the convertLineBreak attribute is that either > we need to have 2 attributes : convertLineBreak & convertSubsequentBlanks > (and I don't think it's really useful), or we need a one in all attribute > like convertLineBreaksAndSubsequentBlanks which isn't very elegant unless we > find another name. > That's why I think just allowing an escape="complete" is quite > understandable and won't clutter the pages with endless tag attributes. > > It's more a question of style than a technical matter, but nevertheless, I > think it's important to have something easy to understand, to remember, and > that doesn't take a full line to type. > > > On Wed, 2005-03-30 at 08:18 -0600, Heath Borders wrote: > 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]
