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

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(a)oracle.com > <mailto:andy.schwartz@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"