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

[Jim Driscoll]

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.