On Mon, Jul 6, 2009 at 10:15 PM, Andy Schwartz
<andy.schwartz@oracle.com> wrote:
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@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.
Also, it's useful for escape="false"
-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.
I really don't like the extra attribute either.
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.
I'm fine with #1 too, but I would think that #2 is less likely to break things (although the examples that Jim gave are pretty bizarre already, so we would only fix something that is really broken).
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.
The real key here is that nothing goes outside the span. The overflow is something I would think everyone agrees is very broken.
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.
In my mind, the whole point of the h:outputText tag is to assign inline text a style, styleClass, id, or formatting/conversion. So I would document this strictly as an inline content tag. A panel should be used for block behavior.
-Dan