Re: Listener Methods

Actually, such functionality has a lot of merit.  Have you checked out Peter 
Eastman's approach at buoy.sf.net?  Buoy has a mechanism for easily adding 
listeners and handling events, thus simplifying gui construction.

Eric

On Tuesday 09 March 2004 08:12, Adam Esterline wrote:
> 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
>
> _______________________________________________
> Forum mailing list
> [email protected]
> http://carlsbadcubes.com/mailman/listinfo/forum_carlsbadcubes.com