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

[Andy Schwartz]

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.

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"