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
