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

Jim Driscoll Jim.Driscoll at Sun.COM
Tue Jul 7 17:35:00 EDT 2009



On 7/7/09 11:13 AM, Dan Allen wrote:
> Comments inline.
>
> On Mon, Jul 6, 2009 at 10:15 PM, Andy Schwartz <andy.schwartz at oracle.com
> <mailto:andy.schwartz at oracle.com>> wrote:
>     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).

No argument there - we'll be breaking badly written code, but we *will* 
be breaking it - we should be clear about that.  And based on previous 
comments on this, I'm concerned that that code may be a significant 
percentage of existing apps (where "significant percentage" is defined 
as > 1%).

However, any implementation change which implemented either 1) or 2) 
would also include a "backward-compat" property which the user could set 
to allow things to continue working.

Given all that, I prefer the simplicity of #1 - just silently fail to 
render children, by overriding getRendersChildren(), and returning true, 
then not rendering them.  Easy to explain - "outputText doesn't render 
any children".

3) is still my preferred choice, since I'd prefer not to break existing 
code - but it sounds like I'm in a distinct minority.  So, I'm OK with 
1), instead.



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

Yep.

Jim




More information about the jsr-314-open-mirror mailing list