Re: Attribute-based event handlers (was: Design Patterns)

[Greg Brown <gk...@mac.com>]

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 <tv...@gmail.com>  
>> 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  
>>> <no...@gmail.com>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.
>>>>
>>>
>>>
>

Re: Attribute-based event handlers (was: Design Patterns)

[Noel Grandin <no...@gmail.com>]

It's not often used, but the HTML spec actually says that you can
specify the language by using a common prefix in the attribute value.

Like so:
  <Button onButtonPressd="java:callMyMethod()">

But I also like your idea of using a default script language. Using
more than one script language is such a weird corner case, that you
should be penalised by needing to use the verbose syntax :-)

-- Noel.

On Thu, Sep 3, 2009 at 02:55, Greg Brown<gk...@mac.com> wrote:
> 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.
>