myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Heath Borders <heath.bord...@gmail.com>
Subject Re: HTMLEcoder and \n
Date Wed, 30 Mar 2005 19:00:30 GMT
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 <kkorhone@cisco.com> 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:svieujot@apache.org] 
> 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
<manfred.geiler@gmail.com> wrote:
> +0.9
> 
> 
> On Tue, 29
> Mar 2005 11:28:09 -0400, Sylvain Vieujot <svieujot@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 <mbroekelmann@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

Mime
View raw message