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

[Jim Driscoll]

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