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

Thu Jul 2 10:20:13 EDT 2009

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)

-allways wrap the output of enclosed children or template text in that
<span>

-if value is specified render that value within the span

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

Document this behavior and the consequences of wrapping children that
render tags not allowed to be wrapped by span in html in the spec.

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