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

[Andy Schwartz]

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

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

Sorry for not responding sooner - bit behind on my JSF email for the 
moment...

Andy