Skip to content
Advertisement

Java and GUI – Where do ActionListeners belong according to MVC pattern?

I’m currently writing a template Java application and somehow, I’m not sure about where the ActionListeners belong if I wanted to cleanly follow the MVC pattern.

The example is Swing based, but it’s not about the framework but rather the basic concept of MVC in Java, using any framework to create GUI.

I started with an absolutely simple application containing a JFrame and a JButton (to dispose the frame hence close the application). The code trailing this post. Nothing really special, just to clearify what we’re talking about. I didn’t start with the Model yet as this question was bugging me too much.

There has already been more than one similar question(s), like these:
MVC pattern with many ActionListeners
Java swing – Where should the ActionListener go?

But non of them was really satisfying as I’d like to know two things:

  • Is it reasonable to have all ActionListeners in a separate package?
    • I’d like to do so for the sake of readability of View and Controller, esp. if there’s a lot of listeners
  • How would I execute a Controller function from within an ActionListener, if the listener is not a sub class inside the Controller? (follow-up question)

I hope this is not too general or vague I’m asking here, but it makes me think for a while now. I always used sort of my own way, letting the ActionHandler know about the Controller, but this does not seem right, so I’d finally like to know how this is done properly.

Kind regards,
jaySon


Controller:

JavaScript


View:

JavaScript

Advertisement

Answer

That’s a very difficult question to answer with Swing, as Swing is not a pure MVC implementation, the view and controller are mixed.

Technically, a model and controller should be able to interact and the controller and view should be able to interact, but the view and model should never interact, which clearly isn’t how Swing works, but that’s another debate…

Another issue is, you really don’t want to expose UI components to anybody, the controller shouldn’t care how certain actions occur, only that they can.

This would suggest that the ActionListeners attached to your UI controls should be maintained by the view. The view should then alert the controller that some kind of action has occurred. For this, you could use another ActionListener, managed by the view, to which the controller subscribes to.

Better yet, I would have a dedicated view listener, which described the actions that this view might produce, for example…

JavaScript

The controller would then subscribe to the view via this listener and the view would call didPerformClose when (in this case) the close button is pressed.

Even in this example, I would be tempted to make a “main view” interface, which described the properties (setters and getters) and actions (listeners/callbacks) that any implementation is guaranteed to provide, then you don’t care how these actions occur, only that when they do, you are expected to do something…

At each level you want to ask yourself, how easy would it be to change any element (change the model or the controller or the view) for another instance? If you find yourself having to decouple the code, then you have a problem. Communicate via interfaces and try and reduce the amount of coupling between the layers and the amount that each layer knows about the others to the point where they are simply maintaining contracts

Updated…

Let’s take this for an example…

Login

There are actually two views (discounting the actual dialog), there is the credentials view and the login view, yes they are different as you will see.

CredentialsView

The credentials view is responsible for collecting the details that are to be authenticated, the user name and password. It will provide information to the controller to let it know when those credentials have been changed, as the controller may want to take some action, like enabling the “login” button…

The view will also want to know when authentication is about to take place, as it will want to disable it’s fields, so the user can’t update the view while the authentication is taking place, equally, it will need to know when the authentication fails or succeeds, as it will need to take actions for those eventualities.

JavaScript

CredentialsPane

The CredentialsPane is the physical implementation of a CredentialsView, it implements the contract, but manages it’s own internal state. How the contract is managed is irrelevent to the controller, it only cares about the contract been upheld…

JavaScript

LoginView

The LoginView is responsible for managing a CredentialsView, but also for notifying the LoginViewController when authentication should take place or if the process was cancelled by the user, via some means…

Equally, the LoginViewController will tell the view when authentication is about to take place and if the authentication failed or was successful.

JavaScript

LoginPane

The LoginPane is kind of special, it is acting as the view for the LoginViewController, but it is also acting as the controller for the CredentialsView. This is important, as there is nothing saying that a view can’t be a controller, but I would be careful about how you implement such things, as it might not always make sense to do it this way, but because the two views are working together to gather information and manage events, it made sense in this case.

Because the LoginPane will need to change it’s own state based on the changes in the CredentialsView, it makes sense to allow the LoginPane to act as the controller in this case, otherwise, you’d need to supply more methods that controlled that state of the buttons, but this starts to bleed UI logic over to the controller…

JavaScript

Working example

JavaScript
User contributions licensed under: CC BY-SA
10 People found this is helpful
Advertisement