One thing that isn't ideal about either approach is that, in an
attribute, you can't specify which scripting language you want to use.
I was thinking that we could add some sort of page-level tag that
allows a caller to define the default scripting language (e.g.
<wtkx:page language="groovy"/>), but this doesn't seem especially
clean. We'd have to ensure that only one instance of this element
existed, and we don't currently have any other need for such a tag.
However, we could easily add a constructor argument to WTKXSerializer
that specifies the default scripting language. This would allow us to
use other scripting languages in attributes, and is also useful for
<wtkx:script> blocks.
It might even make sense to enforce that *only* scripts in the
specified language are supported. That way, we could instantiate the
script engine once - if a null value was provided, it would imply that
the WTKX file doesn't contain any script code at all...
On Sep 2, 2009, at 8:04 PM, Greg Brown wrote:
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.
