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. >> > >
