Blake, sounds good, I was expecting this response and I decided to just file a bug so it wasn't forgotten, but based on your feedback I think we should leave it as is.
FYI, JSF 2 RI disables all client behaviors when the component is disabled, so Trinidad differs. -Andrew On Thu, Dec 10, 2009 at 2:07 PM, Blake Sullivan <[email protected]> wrote: > Andrew, > > Doesn't this get back to the semantics of what the DOM event listeners mean? > Even if my outputText is disabled, the user can still click on it and I > might want to be able to trap that event. The example from DOM itself is > that disabled controls still send DOM events, they just don't perform any > default behavior in response to the event. > > The counter-argument is that because Trinidad has no client component model, > it makes adding a click listener that doesn't fire when the component is > disabled a pain--you need to EL bind the listener on the tag to the same > condition that controls the disabled attribute on the component. > > If the Renderers are already simply not writing any DOM event listeners when > the component is disabled, then I agree we should move the behavior higher > up and in many cases and save the Renderer subclasses the need to code this > themselves. > > -- Blake Sullivan > > Andrew Robinson said the following On 12/10/2009 11:56 AM PT: >> >> While implementing the client behaviors on the Trinidad 2 branch I >> noticed something that does not sit right with me. I noticed that the >> on* attributes (onclick, onmouseover, etc.) are rendered by the >> renderEventHandlers method called from renderAllAttributes in the >> XhtmlRenderer. Nowhere do I see that the renderer is checking the >> disabled attribute, if present, to bypass the event handlers for >> disabled components except manually in the button and link renderers. >> >> I filed this ticket: >> https://issues.apache.org/jira/browse/TRINIDAD-1658 >> >> I think that we should consider making a disabled check in >> renderAllAttributes and skipping the call to renderEventHandlers when >> the component is disable instead of handling this in a per-component >> renderer case. >> >> Opinions? >> >> -Andrew >> > >
