This week's giveaway is in the Spring forum.
We're giving away four copies of REST with Spring (video course) and have Eugen Paraschiv on-line!
See this thread for details.
The moose likes Swing / AWT / SWT and the fly likes Is this really where actionlistener should go? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of REST with Spring (video course) this week in the Spring forum!
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "Is this really where actionlistener should go?" Watch "Is this really where actionlistener should go?" New topic

Is this really where actionlistener should go?

Simon Hunt

Joined: Jul 17, 2006
Posts: 11
I recently programmed my first Java app, which is a utility for a game (the .jar is here:

The GUI consists of a JFrame into which I've placed a "Board" panel and an "Interface" panel. The interface panel has a series of sub-panels showing various bits of information, one of which has the input elements -some text boxes, spinners and a button.

The individual GUI elements are all separate objects extending JPanel. However, whereas I can add the textboxes and spinners to the input panel inside its own code, the button has to be added at the same level as the creation of the Jpanel in order for the actionListener to be able to repaint it using an inner class (it needs access to the "frame" variable). This seems clunky and very non-OO - I'd like to be adding the button along with all the other elements in that panel. Is there a better solution?

here I am adding the button to a panel, which I then add to the input panel - all the other elements on the input panel that do not need actionListeners are added when the inputPanel is created - see below

So really it's this block of code above, between this and the provious comment that "feels", from an OO point of view, that it belongs elsewhere.

The clunkiness is compounded by the fact that I've had to add a whole raft of getters for the references to the textboxes and spinners in order to update the values in the actionListener.

And the input panel class

All the variables and getters below were a work around to extract the information to the actionListener level. However, because repaint needs the frame variable, and there doesn't seem a way of having the button on this level where I think it belongs

That's the end of the work around

The question of how the repaint method can be empty can wait for another time!


[ September 15, 2006: Message edited by: Simon Hunt ]

"I was born in a water moon..."
The Algebraist by Iain M. Banks
marc weber

Joined: Aug 31, 2004
Posts: 11343

Moving to the Swing forum for expert attention.

"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer
Michael Dunn
Ranch Hand

Joined: Jun 09, 2003
Posts: 4632
you're trying to access the frame, from a separate listener class?

if so, maybe something like this will do what you want
if not, can you post a sample runnable program like this, and explain what
you want it to do

Ilja Preuss

Joined: Jul 11, 2001
Posts: 14112
Congrats to your first Java App! You are right that it's "not very OO", but that's quite natural for a beginner - mine did look similar when I started with Java.

I think your design issue actually is more fundamental, in at least two dimensions. Basically I think your panel is doing way too much - a good OO design has lots of little classes that collaborate to get the work done.

For example, your panel looks way too big to me. When I look at your buildInput method, I see opportunities for a number of subpanels being extracted into their own classes, taking over responsibilities for updating themselfes to changes in the world around them.

Second, it might be a good idea to introduce a model for the dialog. When the button gets pressed, the listener would just update the appropriate values in the model by directly reading them from the GUI elements. The model could than update other values that are derived from it (i.e. recalculate those). It then could fire an event to all panels listening (or several events, one for each changed value), and the panels could update their GUI elements accordingly.

That way, all the panels and listeners only had to know the model, and woulud update themselfes automagically whenever there is a change in the model. It wouldn't even matter whether change happened due to a user action, a timed event, a change in a database etc. pp.

I hope that gives you a rough idea on how a "more OO" solution to a GUI design could look like. It probably looks a little bit intimidating to you now, but I suggest you just start playing with the ideas until you get familiar with them. Worked for me...

And come back with your questions!

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Simon Hunt

Joined: Jul 17, 2006
Posts: 11
Just to say (a very belated) thanks for the replies. I'm afraid that my programming only ever happens very sporadically (i.e. out of term time when I get a break from marking), so this is the first time I've looked at it since the summer.

Michael - Am I right in thinking that

Is actually allowing me access to the original "frame" variable? I'll try this out on the next panel class I write. Thanks!

Ilja - I'm now working on a slightly different (but related) app. This one has lots of little panel objects as you suggest. However, my understanding of generating events is too weak currently to implement your
"It then could fire an event to all panels listening (or several events, one for each changed value), and the panels could update their GUI elements accordingly.]"
idea. Are there any sandbox references you could suggest (or even a code snippet if it's reasonably simple)?

I've actually recently gone over to passing the frame variable to the panel objects, which allows all the control code to be in the correct place - each button's listener does it's own little bit, as Ilja suggested, rather than the large ugly listener class you saw last time. This also seems to work fine.

[ January 07, 2007: Message edited by: Simon Hunt ]
Ilja Preuss

Joined: Jul 11, 2001
Posts: 14112
Take a look at - event-listening is typically implemented using the Observer pattern.
Simon Hunt

Joined: Jul 17, 2006
Posts: 11
Thanks Ilja

I'll check this out and return with any questions!


I agree. Here's the link:
subject: Is this really where actionlistener should go?
It's not a secret anymore!