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

[Roger Kitain]

Jim Driscoll wrote:
> 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?
I would think we would want to be a s close to the HTML spec as possible.
>
> 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.
I like Dan's proposal - it seems logical that you could specify the 
value of an outputText component by using the "value"
attribute or wrapping.  If you've got simple content - use the value 
attribute.  If you've got more complex content you could
use the wrapping approach.
>
> 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.