So, I've got a few different things we can do, but my preferred solution is to ignore the wrapped text (i.e., don't traverse the children, don't output anything under foo) for the *ajax* case only, and leave it alone for the full response case, since I don't want to break any existing odd-looking code.

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.

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(a)Sun.COM&gt; To: jsr-314-open(a)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. >

In general, I like Norbert's proposal, with one exception, comments below: On 7/2/09 7:20 AM, Norbert.Truchsess(a)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&lt;Jim.Driscoll(a)Sun.COM&gt; >> To: jsr-314-open(a)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. >>> > > >

FWIW, I have always thought of outputText as a leaf component - not as a container/panel that hosts other components. My preference would be to spec this behavior (ie. children are ignored), though I understand that the concerns about backwards compatibility. (BTW, has anyone looked at how MyFaces handles this?) More comments inline... Jim Driscoll wrote: > In general, I like Norbert's proposal, with one exception, comments below: > > On 7/2/09 7:20 AM, Norbert.Truchsess(a)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? > Sure... h:outputText implements the ValueHolder contract, which means that it can be associated with a Converter to produce a formatted value.

> -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.) > I am not happy with the idea of exposing a new attribute that controls this behavior. Just seems like overkill for what should be a minimal component.

My preferences from favorite to least favorite: 1. Spec that h:outputText is a leaf component: children are not rendered. 2. Spec the behavior that Dan suggested: children are only rendered if the value attribute is not specified.

3. If we cannot do #1 or #2, and we need to render both the value attribute + children, then just tweak the renderer so that it shoves both value + children in the span. I don't especially care which comes first since this is a weird case.

Document this behavior and the consequences of wrapping children that >> render tags not allowed to be wrapped by span in html in the spec. >> > The one slightly odd thing about spec'ing this is that it is not always clear to the page author what type of content (inline vs. block) may be generated by a particular JSF component.

> 1. Spec that h:outputText is a leaf component: children are not > rendered.

On 7/7/09 5:52 PM, Lincoln Baxter, III wrote: > I'm ok with #1 -- "does not render childre"n. I'm also for providing a > "backwards compatability switch" -- but it needs to be documented > clearly in the component PDL docs so that people are aware of it -- > that'll cause unhappy customers. The switch I had in mind was an implementation-specific switch - we have a few of those already in Mojarra. Since the behavior wasn't previously defined in the spec, it doesn't really make sense to document a switch to change back to previous behavior in the PDL, since the PDL is part of the spec, and there was no "previous behavior" in the spec. But I share your concern and frustration about getting folks to understand how to fix it if their existing apps break. Release notes are the usual place where we put such documentation. > This is good in my eyes because it makes a piece of JSF more > intuitive, with the *OPTION* to do something counterintuitive yet > possibly necessary for a number of reasons - if we continue to make > improvements of this sort, then JSF will continue to improve. > > --Lincoln > >>> 1. Spec that h:outputText is a leaf component: children are not >>> rendered.