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

[Dan Allen]

Comments inline.

On Mon, Jul 6, 2009 at 10:15 PM, Andy Schwartz <andy.schwartz at 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 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.


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

-- 
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jsr-314-open-mirror/attachments/20090707/ac90124e/attachment.html