Swing/Echo2 design question

[Moiristo]

I am creating an app in Echo2 (what strongly resembles swing), and I was
wondering what would be a clean implementation for handling actions in
this app. Now, when someone clicks a button, I usually tend to create an
anonymous class, because then I have all displayed components available
that I need. I think however that this often isn't a nice way to do it.
Other possibilities are for example an inner class (actionlistener), or
even a separate class. How do I choose between these three approaches? I
think I forgot because my previous app was in JSF .

 

[John Gagon]

I am creating an app in Echo2 (what strongly resembles swing), and I was
wondering what would be a clean implementation for handling actions in
this app. Now, when someone clicks a button, I usually tend to create an
anonymous class, because then I have all displayed components available
that I need. I think however that this often isn't a nice way to do it.
Other possibilities are for example an inner class (actionlistener), or
even a separate class. How do I choose between these three approaches? I
think I forgot because my previous app was in JSF .

I'd like to know myself. I'm hoping they get Echopoint up to the new
version soon. Please explain "clean implementation for handling
actions". Anonymous instantiations seem to
work fine in Screen objects or various component objects. It has a
Listener/Event/Model fire and handle approach that is pretty commonly
understood AFAIK. Only for more complicated things could you use some
kind of Listener implementation class, instantiated it and handle it
all in the Listener class. Might call it an Adaptor or something if
specific to your code IIRC. Someone correct me if I'm wrong on that.
JSF seems to be heavily tag dependant and I know where you are coming
from there. Going from markup style to a completely java class centric
approach with event listening instead of direct passing seems to play
with the brain's thinking. There is temptation to make direct calls
with it's dependency creating effects instead of registering listeners
and firing/handling events that encapsulate just enough information to
do the job. The event model is very elegant but can be a bit a "heavy".
If you can get away with less classes (and anonymous counts) or
something more generic..or resimplified, the better. The nice thing is
that events tend to be small and the Echo framework good about allowing
control over client chattiness.

John