Inter-panel communication!
I've been trying to find out about making custom events in Java for a silly "freezer simulation" assignment.
The problem is this: My main GUI uses a nested panel for data input, which is a separate class. When the data has been entered by the user into this panel, he/she presses the 'OK' button (on the same panel). How do get the main GUI class to recognise this event? The only way I can think of doing it is to create a custom event and have the main class 'listen' to this input panel class.
Does anyone with a bit more java experience have a simple example of one, or perhaps even a completely different solution. I can't find any helpful examples no the net unfortunately.
Oh by the way if my description of my problem sucks, then my progress so far can be found here: http://homepages.feis.herts.ac.uk/~sj5ak/freezer/
> The only way I can think of doing it is to
> create a custom event and have the main class
> 'listen' to this input panel class.
You are on the right track with this statement. What you are looking for is the Observer design pattern. The JDK actually has built in support for this (or you can just make your own it is quite easy).
To make your own:
1) Create an interface, something like IListenForButtonClicks (use whatever naming convention you like...but doing it like this makes it self-documenting). Have the interface declare a method called something like handleButtonClick();
2) Have your main GUI class implement this inteface.
3) In your nested panel create a member variable for a IListenForButtonClicks object. Name it something like buttonListener.
4) Have your nested panel accept a IListenForButtonClicks interface in its constructor. Set the parameter to your memeber variable.
5) Instantiate your nested panel from your main GUI and pass the main gui class to the nested panel (since it implements IListenForButtonClicks it can of course be referred to as that)...new NestedPanel(this)
6) When the Ok button is pressed in your nested panel simply have it notify your main panel that the button has been pressed by calling: buttonListener.handlButtonClick()
If you prefer to use the built in JDK funtionality check out:
http://java.sun.com/j2se/1.4.2/docs/api/java/util/Observable.html
http://java.sun.com/j2se/1.4.2/docs/api/java/util/Observer.html
You will find it pretty well matches what I described above.
thanks ever so much for that.Thats exactly what i needed to hear. I'm doing it using the "make my own" way and it works a treat too!again, thanks loads!
Somewhat less work would be to have the main GUI implement ActionListener directly. Again, pass a reference to the main GUI to your panel. Now you can directly add your main GUI as the button's ActionListener...
That may be less work, but it's an offensively smelly design.
Perhaps. But I've always been thought to think of unnecessary features as 'smelly design'. And creating a new pair of listener/event types that add absolutely nothing whatsoever seems wasteful to me.
Now if his panel actually took the ActionEvent and somehow transformed into an event describing a meaninful operation on the data he's using. That could, IMO, call for the creation of custom listeners. But even if he did that, I'd be hard-pressed to believe that none of the listener types already defined by swing covers his needs.
Given the specific problem, I think that using the provided
Observer-Observable classes would probably be more than
sufficient. Using an already-defined listener type would also
be reasonable.
I've yet to hear anyone convincingly defend that making GUI classes
extend Listener types is good practice. That's the nature of my
objection. For starters, it's a violation of the Single Responsibility
Principle (SRP). You invariably wind up with a long set of "if .. else if ..
else if.." blocks, which is horrible OO.
> I've yet to hear anyone convincingly defend that
> making GUI classes
> extend Listener types is good practice. That's the
> nature of my
> objection. For starters, it's a violation of the
> Single Responsibility
> Principle (SRP). You invariably wind up with a long
> set of "if .. else if ..
> else if.." blocks, which is horrible OO.
You're right of course. I was mainly countering the IButtonClickListener (or whatever it was) idea. I'm not too hot on capitalized patterns, but I agree wholeheartedly that GUI's implementing listeners is messy (and usually painful, in the end)
