[jsr-314-open] Wrapping Text with a tag - what's the correct behavior?

[Lincoln Baxter, III]

The only reason I can think of to use a plain <h:outputText
value="simpleValue" />, aside from binding, is for the default HTML
encoding that it provides -- otherwise, using EL directly in the page
can lead to HTML injection or XSS attacks. Unless I'm mistaken and
that's provided by facelets by default.

-Lincoln

On Thu, Jul 2, 2009 at 12:48 PM, Jim Driscoll<Jim.Driscoll at sun.com> wrote:
> In general, I like Norbert's proposal, with one exception, comments below:
>
> On 7/2/09 7:20 AM, Norbert.Truchsess at t-online.de wrote:
>>
>> I'd propose<h:outputText>  to act the following way:
>>
>> -for consistency allways render a<span>  (no matter whether id is
>> specified or there are enclosed children or not). That allows to be
>> referenced the by css-selectors without the need to explicitly specify
>> an id. (Actually besides the fact that template-text lacks a
>> binding-attribute to bind textual output as a component to a managed
>> bean this use-case is justification for keeping<h:outputText>  not just
>> for historical reasons now that with facelets one can use expressions
>> anywhere within the template text)
>
> That brings up a good point - is there any reason any longer to use this tag
> in a facelets environment besides setting up a binding?  If not, then a
> mention to that effect in the facelets PDL doc is certainly appropriate.
>
> The <span> effect is also achievable via panelGroup, of course - and if we
> were designing a component library from scratch, it seems like there would
> be good cause to just leave outputText out entirely.  But we're stuck with
> what we have.  So, this sounds like a good idea - it's certainly more
> natural to mark up a simple EL variable with outputText if you need to
> access it via Ajax or CSS that wrapping that variable with a panelGroup.
>
>> -allways wrap the output of enclosed children or template text in that
>> <span>
>
> This is necessary for Ajax, as well as CSS, which is what brought up the
> issue.  So I think that any solution needs to require this.
>
>> -if value is specified render that value within the span
>
> This is the current behavior, so yes.
>
>> -if value is specified and there are enclosed children, prepend or
>> append the value to the output rendered by the children. Allow to
>> controll whether the value is prepended by setting a new attribute
>> 'prependValue' to true (defaults to 'false', which means the value is
>> appended when prependValue is not set or set to false).
>
> Since the current behavior is to prepend, I would like to suggest that that
> be the default.  Yes, that's not ideal, but it will break the fewest number
> of existing apps, which should be a primary goal.  Any solution we come up
> with should strive to not make pages suddenly render in a way that's
> noticable to the end-user.  (That's why I like Norbert's solution much
> better than my previous proposal.)
>
>> Document this behavior and the consequences of wrapping children that
>> render tags not allowed to be wrapped by span in html in the spec.
>
> Since this behavior is currently unspecified, I can implement all this in
> the RI (except the prependValue attribute), and would like to, before we
> ship the next release, so that we can get meaningful feedback before FCS.
>  That means doing it by COB next week.
>
> So - if everyone could comment on this quickly, I'd appreciate it. Whatever
> we decide, I'd like it decided by next Wednesday at the latest.
>
> Jim
>
>
>> - Norbert
>>
>> -----Original Message-----
>>>
>>> Date: Wed, 01 Jul 2009 20:07:40 +0200
>>> Subject: Re: Wrapping Text with a tag - what's the
>>> correct behavior?
>>> From: Jim Driscoll<Jim.Driscoll at Sun.COM>
>>> To: jsr-314-open at jcp.org
>>
>>> I agree that we should specify this.
>>>
>>> I should probably, at this point, mention exactly what outputText is
>>> currently doing, so we can talk about how it should act.
>>>
>>> outputText is rendered in it's entirety in the encode end section of
>>> the api.  This is certainly, as Dan says, a bug.  It also allows
>>> children to be rendered, provided that the wrapping outputText is
>>> rendered.  I'd actually argue that we should just not allow children
>>> on outputText components.
>>>
>>> Consider this contrived example:
>>>
>>> <h:outputText value="after">Count:<h:commandButton type="button"
>>> value="button"/>  </h:outputText><br/>
>>>
>>> Right now, this returns:
>>>
>>> Count:<input type="button" name="form:j_id-519344002_6caa9f6"
>>> value="button" />after<br />
>>>
>>> Adding an id, to force the span to be rendered, gets you:
>>>
>>> Count:<input type="button" name="form:j_id-519344002_6caa9f6"
>>> value="button" /><span id="form:test">after</span><br />
>>>
>>> Removing the value,
>>>
>>> <h:outputText id="test">Count:<h:commandButton type="button"
>>> value="button"/>  </h:outputText><br/>
>>>
>>> you then get:
>>>
>>>
>>> Count:<input type="button" name="form:j_id-519344002_6caa9f6"
>>> value="button" /><span id="form:test"></span><br />
>>>
>>>
>>> Notice that the contents of the outputText are *outside* the span.
>>> This is the original bug, and not addressed by Dan's proposal.
>>>
>>> Moving them inside the span opens up other issues, since spans aren't
>>> allowed to wrap just any old tag, there are restrictions.  Should we
>>> care?
>>> So, if we're going to disallow wrapped values in some cases, I'd like
>>> to propose that we simply disallow wrapped values in all cases,
>>> turning off the ability to render children.   This will break some
>>> existing code - but the odds are, it wasn't working terribly well
>>> anyway.
>>>
>>> If we instead adopt Dan's proposal, only wrapping in the case that
>>> value is unspecified, we'll *still* need to spec it that the wrapping
>>> span actually starts at encode begin, not encode end.
>>>
>>> So - which of these two options do people prefer?  I'd like to change
>>> the impl *now*, and then spec the behavior in 2.1.
>>>
>>> Jim
>>>
>>> On 6/19/09 10:18 AM, Dan Allen wrote:
>>>
>>>> I had a private conversation while the mailinglist was out of order
>>>> and I want to bring the conclusions that were drawn back online.
>>>>
>>>> To restate the problem, how does JSF handle the case when both a
>>>> value attribute and body markup are provided for UIOutput
>>>> components?
>>>> 1. We need to spec the behavior so there is consistency across
>>>> implementations
>>>> 2. Ajax should not be handled as a special case (consistency across
>>>> usage scenarios)
>>>> 3. If the value attribute is used, and the value is not empty, the
>>>> body markup should be ignored.
>>>>
>>>> The following use case was put forth that relies on the unspecified
>>>> behavior today:
>>>>
>>>> <h:outputText style="border: 1px solid blue" value="#{escapedText}"
>>>> escape="false" rendered="#{renderCondition}"><img
>>>> src="img/exclmark.gif" alt="!" /></h:outputText>
>>>>
>>>> It's semantically incorrect to consider both the value and body
>>>> content.
>>>> That would be an attempt to use a shorthand which I don't think
>>>> should be supported. The proper thing to do is introduce additional,
>>>> nested tags.
>>>>
>>>> -Dan
>>>>
>>>> --
>>>> Dan Allen
>>>> Senior Software Engineer, Red Hat | Author of Seam in Action
>>>>
>>>> http://mojavelinux.com
>>>> http://mojavelinux.com/seaminaction
>>>> http://in.relation.to/Bloggers/Dan
>>>>
>>>> NOTE: While I make a strong effort to keep up with my email on a
>>>> daily basis, personal or other work matters can sometimes keep me
>>>> away from my email. If you contact me, but don't hear back for more
>>>> than a week, it is very likely that I am excessively backlogged or
>>>> the message was caught in the spam filters.  Please don't hesitate
>>>> to resend a message if you feel that it did not reach my
>>>> attention.
>>>>
>>
>>
>>
>