All very valid arguments...
On Sep 2, 2009, at 8:03 PM, Todd Volkert wrote:
Letting this simmer a bit since I wrote the proof-of-concept, I
still like
the ButtonPressListener.buttonPressed="" syntax better, for the
following
reasons:
1. It's very clear which event method you're implementing, because
the
interface is right there in your face. The "on..." syntax makes
Joe User
wonder "just what events are supported", and there's no clear
association
with the Java code that tells them where to look.
2. It's *much* more efficient. Scanning every method, both
declared and
inherited, and then scanning every interface method for the event
listener
interfaces found, is highly inefficient.
3. It introduces less black magic into WTKXSerializer, which is
not a
point to be taken lightly.
-T
On Wed, Sep 2, 2009 at 7:25 PM, Todd Volkert <[email protected]>
wrote:
Moving over to pivot-dev, as this is becoming more of a dev thread.
So I wanted to test your suggestion to see how the code would look
- sort
of as a proof of concept. See attached file for the source code
and the
output. It produces the following output.
The bottom line is: you're right - it's not too tough to do, and
the code
isn't that messy :). There's a different issue here though that
would then
need to be discussed: is it ok to change WTKXSerializer to have a
policy
that any attribute beginning with /on[A-Z]/ is to be taken as an
event
listener? It's not so much a parsing problem as a design one --
right now,
WTKXSerializer doesn't contain any such "if the attribute name is
X, then
special case it" logic. One could argue that adding such a special
case
will encourage other special cases, and before you know it, the
simplicity
of the design is gone, and it'll be hard to digest exactly how to
use WTKX.
Now, on the other hand, we could say that the policy is to look for a
setter ("setOnMouseClick", for instance), and only if one is not
found (and
the attribute matches /on[A-Z]/) do we look for event handler
methods.
Given how simple my test case was to write, I'm actually not that
against
this (at least not as against it as I thought I'd be) :). What do
others
think?
-T
On Wed, Sep 2, 2009 at 4:38 PM, Noel Grandin
<[email protected]>wrote:
But how would it know where to look, and which interfaces
constituted
"listener" interfaces? I think Todd's >
In Pivot, anything method that returns a subtype of ListenerList is,
by definition, a listener API.
It's not hard to use reflection to scan for methods that match that
pattern, and then scan the appropriate interface class to find the
right method.
IMNSHO, Todd's syntax looks pretty long-winded and awkward to use,
especially if you're done some HTML programming.
-- Noel.
