HTMLEcoder and \n

[Sylvain Vieujot <sv...@apache.org>]

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.

Re: HTMLEcoder and \n

[Heath Borders <he...@gmail.com>]

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 <sv...@apache.org> 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
> <sv...@apache.org> 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 <sv...@apache.org>
> 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
> <ma...@gmail.com> wrote: > +0.9 > > > On
> Tue, 29 Mar
> 2005
> 11:28:09 -0400, Sylvain Vieujot <sv...@apache.org>
> 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
> <mb...@psi.de> 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
hborders@mail.win.org

Re: HTMLEcoder and \n

[Sylvain Vieujot <sv...@apache.org>]

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 <sv...@apache.org> 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 <sv...@apache.org>
> > 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
> > <ma...@gmail.com> wrote: > +0.9 > > > On Tue, 29 Mar
> > 2005
> > 11:28:09 -0400, Sylvain Vieujot <sv...@apache.org> 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
> > <mb...@psi.de> 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. > > > > > > > > >
> > > > 
> 
> 
> 
> 

Re: HTMLEcoder and \n

[Heath Borders <he...@gmail.com>]

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 <sv...@apache.org> 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 <sv...@apache.org>
> 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
> <ma...@gmail.com> wrote: > +0.9 > > > On Tue, 29 Mar
> 2005
> 11:28:09 -0400, Sylvain Vieujot <sv...@apache.org> 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
> <mb...@psi.de> 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
hborders@mail.win.org

Re: HTMLEcoder and \n

[Sylvain Vieujot <sv...@apache.org>]

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 <sv...@apache.org> 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 <ma...@gmail.com> wrote: > +0.9 > > > On Tue, 29 Mar
> > 2005 11:28:09 -0400, Sylvain Vieujot <sv...@apache.org> 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
> > <mb...@psi.de> 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. > > > > > > > > >
> > > > 
> 
> 

Re: HTMLEcoder and \n

[Heath Borders <he...@gmail.com>]

We would still need a separate flag in the component, this would just
require more advanced logic in the tag.

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;


On Tue, 29 Mar 2005 22:27:21 -0400, Sylvain Vieujot <sv...@apache.org> 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 <ma...@gmail.com> wrote: > +0.9 > > > On Tue, 29 Mar
> 2005 11:28:09 -0400, Sylvain Vieujot <sv...@apache.org> 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
> <mb...@psi.de> 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
hborders@mail.win.org

Re: HTMLEcoder and \n

[Sylvain Vieujot <sv...@apache.org>]

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
> > <ma...@gmail.com> wrote:
> > > +0.9
> > > 
> > > 
> > > On Tue, 29 Mar 2005 11:28:09 -0400, Sylvain Vieujot <sv...@apache.org> 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 <mb...@psi.de> 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. > > > > > > > > > >
> > > 
> > 
> > 

Re: HTMLEcoder and \n

[Sylvain Vieujot <sv...@apache.org>]

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
> <ma...@gmail.com> wrote:
> > +0.9
> > 
> > 
> > On Tue, 29 Mar 2005 11:28:09 -0400, Sylvain Vieujot <sv...@apache.org> 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 <mb...@psi.de> 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. > > > > > > > > > >
> > 
> 
> 

Re: HTMLEcoder and \n

[Heath Borders <he...@gmail.com>]

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
<ma...@gmail.com> wrote:
> +0.9
> 
> 
> On Tue, 29 Mar 2005 11:28:09 -0400, Sylvain Vieujot <sv...@apache.org> 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 <mb...@psi.de> 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
hborders@mail.win.org

Re: HTMLEcoder and \n

[Manfred Geiler <ma...@gmail.com>]

+0.9


On Tue, 29 Mar 2005 11:28:09 -0400, Sylvain Vieujot <sv...@apache.org> 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 <mb...@psi.de> 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. > > > > > > > > > >

Re: HTMLEcoder and \n

[Sylvain Vieujot <sv...@apache.org>]

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
> <mb...@psi.de> 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.
> > >
> > >
> > >
> > >
> > 
> > 
> 
> 

Re: HTMLEcoder and \n

[Heath Borders <he...@gmail.com>]

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
<mb...@psi.de> 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
hborders@mail.win.org

Re: HTMLEcoder and \n

[Sylvain Vieujot <sv...@apache.org>]

We talked some weeks ago about having an escape="all" to encode the \n
into <br/>

Just to let you know this is now useless as we can do the same using :
<x:inputTextarea value="my text with some \n s"
displayValueOnly="true"/>

Sylvain.

On Tue, 2005-03-29 at 08:59 +0200, Mathias Broekelmann 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. 
> > 
> > 
> > 
> > 
> 

Re: HTMLEcoder and \n

[Mathias Broekelmann <mb...@psi.de>]

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. 
> 
> 
> 
> 

Re: HTMLEcoder and \n

[Oliver Rossmueller <ol...@tuxerra.com>]

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. 



-- 
Oliver Rossmueller
Software Engineer and IT-Consultant
Hamburg, Germany
http://www.rossmueller.com