Swing

[Anna Hays]

Hello, I am completely new to Swing, so can someone please help me out on some dumb questions please?
I have 3 buttons on the same class (or JFrame), I need a few actions to triggered on which button. Do I write 3 classes that implements ActionListener??? I have a muck around with the tutorials on the Sun website and the ones I looked at is implements on the main class...
If I implement all the ActionListener as inner classes for every button, that will be like messive number of them, is this a good idea? It will be hell confusing for the junior I reckon...
Thanks!
[ April 15, 2004: Message edited by: Anna Kafei ]

[Zafer Abu saeed]

Hello Anna,
I was looking for a solution for this too..
After reading many posts and articles, I believe that:
1- You should avoid the "Single ActionListener with a switch statement to detect the clicked button".
2- A better way is to use an individual class (that implements ActionListener) for each button.
3- You can use the Command Pattern:

  
public interface Command {
  public void execute();
}

public class SearchButton extends JButton implements Command {
  ...
  public void execute() {
     ... serach logic ...
  }
}

Then define a similar class for the other two buttons,
Make the main JFrame listens to this buttons (be the ActionListener)
and implement its actionPerformed method as the following:

public void actionPerformed(ActionEvent evt) {
  ((Command) evt.getSource()).execute();
}

I think the number of classes is not a problem.
I hope this will help, and I would like to see more posts about this topic.

[Jacques Bosch]

Hi Anna.
Why don't you just keep the action listener as an anonymous inner class right where you add it to the button. Generally that is best, IMHO, for actions that will only be used once.
Like this:

findButton.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent ev) {
doFind();
}
});

[Jacques Bosch]

I think Zafer's solution is good too, although a bit more complex than might be needed here. But nice.

[Mark Spritzler]

OK, here goes.
MVC pattern which stands for Model View Controller. This means that there is a complete seperation of code for the GUI, the business logic, and the data. The Model is the data. The view is the GUI and the Controller is the class that controls everything. It will handle the Actions for you, it will have the business logic, and it will pass the model to the view to display.
How do you do this in Java.
In the GUI you will have Hook methods. like such:

 
/**
    * This method is a hook to allow the Controller to define the action for the Search JButton.
    * @param ActionListener action Action to assign to the Search JButton.
    */
    public void searchAction(ActionListener action) {
        searchButton.addActionListener(action);
    } 

What this does is allow any class that Implements ActionListener to pass a reference of itself to the GUI to be able to Listen to the Actions of the JButton on my GUI for searching.
Now there are two trains of thought and both are fine for the assignment. In my assignment I have the controller implement ActionListener and have one method that hooks all the methods in the Controller to each Action in the GUI.
Example:

 
/**
    * This method assigns the listeners to the objects on the gui that need listeners.
    * It then maps the methods of this class that fire when the action occurs on the GUI.
    */
    private void assignActionListeners(){
        frontEnd.searchAction(new ActionListener(){
            public void actionPerformed(ActionEvent e){
                searchFlight();
            }
        });
        frontEnd.bookAction(new ActionListener(){
            public void actionPerformed(ActionEvent e){
                bookFlight();
            }
        });
    } 

In the assingActionListener, I use Anonymous inner classes that will basically have the SearchButton when pressed makes the searchFlight() method, in the Controller, run.
The Controller has a reference to the GUI class.
You can further decouple this by using Action classes that holds a reference to the Controller and the GUI without the GUI or COntroller having any references to each other. This is a nice solution, but you can receive perfect marks, like I did, in this section using my solution, which isn't completely decoupled. Meaning the Controller knows the GUI. But my definition of Controller is one that controls.
Good Luck, and I hope this helps.
Having the ActionListeners in the GUI or as one class that has a big switch statement is a bad design.
Mark

[Baruch Sadogursky]

Talking about Command design pattern, why not to use javax.swing.Action class??? It was invented to solve your question, and it implements the Command pattern exactly!
[ April 15, 2004: Message edited by: Baruch Sadogursky ]

[Anna Hays]

Thank you for all your interesting feedbacks! Which solutions are commonly used for work industry do you think? Is there a big article talking about this somewhere on Sun's website? I can't seem to find anything so I find it really hard to start on this section of the assignment...
Thanks again!

[Maria Lepschy]

I have also a guestion regarding MVC.
I have implemented like in Max book, that means I have a Controller handling the business logic and in the view I have a reference to the Controller and I handle all events in inner classes. Is this bad?
For the configuration window I don't use MVC, all is in the view because I thing in this case is not worth to have many classes. What is your meaning?
Maria

[Zafer Abu saeed]

Hello Ranchers,
I don't know why every time I add a post it becomes the last one in the thread ?! (I start feeling that there is a problem with my
questions ?)
I hope this one will not be..
I have a Button and a MenuItem supposed to do the same work (so they have a shared listener), I think using javax.swing.Action is preferable in such situation.
Now I have decided to use the "Hooks" pattern (method) suggested by Mark, but I couldn't apply it because I have Actions.
So, while you can use a hook like this for ActionListeners:

  
public class View {
    ....
    public void setSearchAction(ActionListener lis) { 
       searchButton.addActionListener(lis);
       searchMenuItem.addActionListener(lis);
    }
}

you have to use

 setAction(Action) 

instead of

 addActionListener(ActionListener) 

when dealing with Actions.
Could I use the hooks method with Actions instead of ActionListeners ? (So I will make every button and menuItem takes an Action, even though some actions will be added to only one component -only a button, or only a menuItem).
Or do you have a better idea ?

[Andrew Monkhouse]

Hi Zafer,

I don't know why every time I add a post it becomes the last one in the thread ?! (I start feeling that there is a problem with my questions ?)

I think for this question at least, you may be using an API that most candidates do not use, so they don't feel comfortable with answering it. If you would like to, you could ask the bartenders to move your "O-O event handling.." post into the Swing / JFC / AWT forum, where you may get more answers.
From reading the documentation on setAction(Action), it says that setting the Action does not affect ActionListeners independently added with addActionListener. Can you therefore continue to add action listeners independently?
Regards, Andrew

[Zafer Abu saeed]

Thanks, Andrew.

From reading the documentation on setAction(Action), it says that setting the Action does not affect ActionListeners independently added with addActionListener. Can you therefore continue to add action listeners independently?

I think using addActionListener and setAction(Action) on the same component will be confusing, since the class Action already implements ActionListener, and by adding another class that implements ActionListener, we will have two listeners, one of them (the Action) is do-nothing listener..
Actually, I'm tired because of this issue (event handling design)
, still this is my first decision in the implementation, I think it will be a long road.. so I will implement event handling as a collection of Action classes, and try to defend.. May be it doesn't worth all this hesitation.

[Stephen Galbraith]

The good thing about Action IMHO is the ability to set tooltips, icons etc in one place and then you can register it with the various swing Menu widgets/ JButtons and they'll get the appropriate icon etc and "self manage" (albeit via the Action object).
If you don't need to have the Action registered with various (many?) components then you may think to yourself, "it's all too much hassle this Action class thing - I'll just do an ActionListener". So it all boils down to convience. Is it more hassle creating the Action or the ActionListener?
Steve