Re: Listener Methods

You are right.... It is complicated.    I usually don't like to use 
reflection for those very reasons.   It does however reduce the amount 
of non-business logic code that the user writes.   Is this a good 
reason (less GUI wiring code)? I don't know.    I proposed the idea, 
because swixml is full of reflection (so a little more never hurt :).

I think in some ways it makes the client more readable.   You can have 
a very well named method, on the client, that is your event handler.    
So your methods could be things like:

public void goButtonPress()
public void newSelectionInUserList()

In a way it is sort of like recreating the event handling in C#, in 
Java.   I don't know if C# is a bad word in this group, but C# was the 
original seed for the idea.

Here is a link to some C# code that shows how they use regular methods 
for event handling.

http://www.devarticles.com/c/a/C-Sharp/Event-Handling-With-C-sharp/3/

Maybe I did not did not convey the proxy stuff very well.   Here is a 
link to the sun article that talks about using dynamic proxies for 
swing apps.

http://java.sun.com/products/jfc/tsc/articles/generic-listener2/

Thanks for the feedback.....   I enjoy these kinds of discussion.

AE

On Mar 9, 2004, at 12:53 AM, <[email protected]> wrote:

> Hello Adam,
>
> I read your code and found it a bit difficult what you where trying to 
> achive.
>
> You use a lot of reflection to invoke a method of an interface you 
> both know.
> Why not calling it directly and creating a inner class for this 
> purpose? Sure,
> you are able to return Object instead of ListSelectionListener and to
> introduce another parameter with the interface-class you want to
> implement but IMHO there is a much simpler possiblity.
>
> There already exist methods in the GUI classes for adding listeners,
> like JList.addListSelectionListener().
>
> My idea would be to accept a 'mouseListener="myMouseListener"'
> attribute in the XML-File. In fact, the addXXXListener method is not
> that different from setYYY, so there is only a minor change
> concerning swixml (changing the filter which accepts only method
> named "set*" having one argument). The result is you are able
> to use attributes declaring ListSelectionListeners. Sure, you can not
> have all public methods wire to your list selection listener but this
> is IMHO hardly the common use. If two or three "callable functions"
> are enough to choose from, IMHO (I want to emphasise this really,
> perhaps I'm wrong) it is ok to have the same number of inner
> classes.
>
> What do you think?
>
> Frank
>
> List for Users of Carlsbad Cubes' Technologies and Products schrieb am 
> 08.03.04 16:54:20:
>>
>> Wolf,
>>
>> Here is my idea.   I am not very good at describing ideas, so I have
>> attached code that I hope explains.   I really like swixml because it
>> really allows the separation of GUI creation from business logic.    I
>> would like to see it go just a step further than it does now.   I am 
>> in
>> total agreement about not putting any code ("scripting") in the GUI
>> definition.   I would like for the framework to do some of the wiring
>> that really has nothing to do with the business logic.   I have 
>> created
>> an example and attached it below.
>>
>> Main points of interest:
>>
>> masterListSelectionChanged() method on the MainWindow class.
>>
>> onChange attribute of the "masterList" list element
>>
>>
>> The idea would be to have the framework wire listeners to methods on
>> the client.   In the mainwindow.xml the first list element has a
>> onChange attribute that contains the name of a public method on the
>> client (MainWindow).   I would like the framework to wire up the
>> ListSelectionListener.valueChanged method to the
>> masterListSelectionChanged method on the client.
>>
>> I have attached some code in the ReflectionUtils class that allows you
>> to wire any interface method to an object method.   I don't think that
>> the ReflectionUtils class is production ready, but it demonstrates the
>> concept.
>>
>> I am open to any and all discussion.
>>
>> AE
>>
>>
>> <hr>
>> _______________________________________________
>> Forum mailing list
>> [email protected]
>> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
>>
>
>
>
>
> _______________________________________________
> Forum mailing list
> [email protected]
> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com
>