[jsr-314-open] [Behavior] Why is HtmlOutputText not a ClientBehaviorHolder ?

[Matthias Wessendorf]

On Tue, Jan 12, 2010 at 4:02 PM, Andy Schwartz <andy.schwartz at oracle.com> wrote:
> Hey Lincoln -
>
> Lincoln Baxter, III wrote:
>>
>> Html <span> elements can have onClick, onBlur, and lots of other events,
>> as well.
>
> Sure, I understand and didn't mean to suggest otherwise.  My point is that:
>
> a. h:outputText, unlike the other standard components, doesn't provide
> access to these events via standard attributes.
> b. If we are going to add support for attaching client behaviors, we should
> probably be consistent and expose attributes as well.
> c. I am somewhat concerned that doing this can have impact on the
> performance of h:outputText.
>
> Regarding performance - my main concern is that this might add overhead in
> the stamping case (eg. when stamping out h:outputText elements inside of an
> h:data).  So, I am open to a solution here, but just want to make sure that
> consider the performance implications before we beef up h:outputText.
>
>
>> People will probably end up having to attach this behavior manually.
>>
>> This makes me wonder:    Do we have a mechanism for attaching behaviors to
>> "snippits" of HTML (more than links and buttons, say, divs / spans) on the
>> output page, or do we need to address that as well? I see a use for being
>> able to attach behaviors to any element on the HTML page.
>
> The client behavior model is UIComponent-centric - ie. behaviors are
> attached to components.  So, for the div/span cases, we would need some
> component to attach to.  I was thinking that h:panelGroup should be
> sufficient for this.  Does this sound reasonable or are you looking for
> something else?
>
> BTW, h:panelGroup also provides a way out for the h:outputText case - ie.
> the h:outputText could be wrapped in an h:panelGroup that holds the
> behavior.  Not sure whether folks are happy with this as our recommended
> solution, but wanted to mention it as a work around that is available now.

I think that using h:panelGrid is not perfect, but it is better than
abusing <label>.

-Matthias

>
> Andy
>
>>
>> The next question is: Do we need such a mechanism? That's, for the most
>> part, the kind of behavior that a library like JQuery would provide, though
>> we lose the hooks into JSF that come with behaviors.
>>
>> --Lincoln
>>
>> On Mon, Jan 11, 2010 at 2:24 PM, Andy Schwartz <andy.schwartz at oracle.com
>> <mailto:andy.schwartz at oracle.com>> wrote:
>>
>>    Hey Matthias -
>>
>>
>>        Why is HtmlOutputText not a ClientBehaviorHolder ?
>>
>>
>>    I believe that the answer is that we only exposed ClientBehavior
>>    events/attach points for cases where components already exposed
>>    DOM event handlers.  Since h:outputText does not expose any DOM
>>    event handlers (eg. no "onMouseover" attribute), we didn't surface
>>    any ClientBehavior attach points either.  So, a related question
>>    is whether h:outputText should expose attributes for all of the
>>    relevant DOM event handlers.  Personally I don't see much value in
>>    this - would prefer to keep h:outputText small/simple - but I am
>>    open to discussion on this point.
>>
>>    Andy
>>
>>
>>
>>
>> --
>> Lincoln Baxter, III
>> http://ocpsoft.com
>> http://scrumshark.com
>> "Keep it Simple"
>
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf