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

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.