On Sun, Jan 10, 2010 at 7:23 AM, Matthias Wessendorf <matzew(a)apache.org&gt; wrote: > > Why is HtmlOutputText not a ClientBehaviorHolder ? > > sure, while <h:outputText value="foo" /> renders as plain text, > some slightly more "complex" outputText renders with a <span>: > > <h:outputText style="color:red" value="blah blah blah" /> > > IMO it is a limitation that outputText is not a ClientBehaviorHolder; > > Imagine that you want to do some stuff (e.g. insert/remove a "context > menu") on mouseover/out. > Currently you need to use <outputLabel> for that. > > IMO it is a bit lame. > So, if a ClientBehavior is present, why not rendering the beast as > <span ....>Blah blah...</span> ?? +1 The language would have to state that a wrapper tag (such as <span>) is required in this case, just as it is when styles are specified. -Dan -- Dan Allen Senior Software Engineer, Red Hat | Author of Seam in Action Registered Linux User #231597 http://mojavelinux.com http://mojavelinux.com/seaminaction http://www.google.com/profiles/dan.j.allen

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

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"