We Keep Coding

How to deal with events in Java MVC

I'm creating my first "bigger" application in Java. As MVC is only pattern I know, I decided to use it. But there's something wrong with this concept.
For example. I need an Action (or generally event) fired from 2 places (from Button in frame and MenuItem). It has to do changes in at least 2 places and in the model.
I've got some ideas, but they seem wrong:
Pass the controller object to every view element, so newly created actions could use controller's methods to modify rest of the application.
Make controller static (for same reasons)
Make controller only model listener
Please tell me how to build it. Or give me some links to some easy to analyse applications.
Source of my project is here, if anyone wants to have a look: https://github.com/Arrvi/ColorExtractor

You are correct to use Action to encapsulate functionality for use by disparate components such as menus and buttons. A spectrum of examples is cited here. As regards MVC, recall that Swing uses a separable model architecture, examined here. In effect, the user is the controller, and not every interaction needs to pass through your application's controller.

How does MVC/MVP work in a Swing app?

I have been asked to revamp an existing JDialog that is a child container of an in-house Swing app. I will be re-writing the dialog from scratch and have been asked to lead the charge towards making the Swing app resemble a true MVC/MVP architecture (so my JDialog revamp will be the first of many pro-MVC changes to the app itself).
I understand MVC/MVP as it pertains to web apps:
Controller - is what the web app framework dispatches to handle HTTP requests; typically consists of multiple methods, where each "controller method" handles the request for a slightly different URL
Model - the DAO or POJO/bean representing call-specific data; controller fetches the Model from the DB and injects it into the View
View - the mechanism that ultimately produces HTML/JSP that will be sent back to the client/requester
This is not how all MVC/MVP web frameworks operate, but is the general idea.
But I'm struggling trying to determine how to translate this to a Swing app. In the Swing app, you have:
The JDialog itself
All the UI widgets (JButtons, JTextFields, etc.) that make up the "view" of the dialog
The action/event listeners for all the UI widgets which collectively make up the "business logic" for how the dialog will operate when the user interacts with the view
All the other "UI glue code" (setting which widgets will be enabled/disabled, setting their sizes and positions on screen, setting their tooltip texts, etc.)
Plus a lot of other stuff
So I ask: how do I organize all the code necessary for a functioning JDialog using an MVC/MVP architectural pattern? Also, if there are any articles, tutorials, or existing open souce projects that showcase MVC/MVP Swing apps, I am interested in them as well. Thanks in advance!

As discussed here, Swing MVC hinges on the observer pattern used to propagate model changes back to any listening view(s). As a result, much depends on the components in your JDialog. If your dialog must be modeless, the examples here and here may be helpful.

Since there are many valid recipes out there, I'll only discuss what I use: a modified MVP design which also borrows ideas from The Humble Dialog Box.
Basically, create your GUI with as little application logic as possible (zero is the goal). Create "presenter" classes (similar to Controllers) that have a handle to the GUI and inject the appropriate listeners onto the UI.
Some benefits:
Since all application code is out of the UI, your code is now 100% testable.
You can quickly prototype your GUI without having to launch your app everytime, which can be a big time-saver.
Separation of concerns makes code easier to read/maintain.
Your GUI code will be Swing only. A new team member who isn't familiar with your app but is familiar with Swing can jump right in.
With regard to Swing's implementation of MVC, we actually don't care. That's Swing's business. We assume Swing works (which it usually does). True, we need to know these sorts of things for writing custom renders, editors, models, etc., but those are details that the application framework (which is what I think you're asking about) doesn't need to know or care about, for the most part.

I would do like this:
MyModel model = engine.getDataFromDatabase();
myController.displayDataOnMyCustomView(myPresenter, model);
And at controller side, probably will remove a lot of listeners, set the data based on model, set sizes, locations and any other state representing stuff and finally re-add the listeners.
The myPresenter should be a custom JDialog with various basic ui elements (Component)on his UI tree.

Java Swing GUI code structure

I have a class which extends JFrame and forms the GUI of my program. I want to use the GUI for two main purposes:
I want the user to be able to input values to the program.
I want the GUI to display values created by my program.
Considering my class has a lot of GUI elements, the source file is already rather large and It does not seem like good practice to bundle all the program code in with the GUI code. I'm wondering what is the best way to structure my code? I believe there is an issue where requirement 1 creates a dependency from the GUI to the program code, and the second requirement does the opposite.
So, I want one class for my GUI which contains all my GUI related tasks. I then want another class for my program logic. I should then be able to call methods from the program logic class from the GUI and vice versa.

Sounds like you are looking for a textbook MVC (Model-View-Controller) design pattern. I recommend you google "MVC Design Pattern" for summaries and use cases. That being said, you might want to put your program logic into a "Singleton" class (again, google "Singleton Design Pattern"). A properly implemented Singleton should be accessible from any other class in your code.
Consider also a third middle class which acts solely for data storage, you put values into it for storage, and you fetch values from it for work. This now creates 3 clear segments for your code, the Data (the Model), the GUI (the View), and the logic (the Controller). Voila, you've just implemented the MVC (Model-View-Controller) design pattern...

The business logic should not depend on the GUI logic.
Have your GUI take inputs from the user. Call business logic methods with these inputs as method arguments, and use the values returned by the methods to display the result in the GUI. The GUI thus depends on the business logic, but the reverse is not true.
If the business logic must callback the GUI, it should do so via well-defined GUI-agnostic callback interfaces, or listeners. For example, you could register a ProgressListener on some business logic object, and this object would call back the progress listener. The GUI would have an implementation of the ProgressListener which would in fact update some progress bar or text area. But the business logic only depends on the interface, and not on the specific implementation.

I'm not sure there is one "best" way to structure GUI code. As a general rule though, you should follow MVC. Your program (Model) should never directly depend on your View code. What it's allowed to do is notify the controller that the model (or parts thereof) changed, and that whichever views are currently displaying said part of the model should be updated.
Swing already provides this abstraction layer for some of its types of component, most of the classes are (somewhat confusingly) suffixed with Model. A simple example you could look at would be BoundedRangeModel. There should be only one instance of such a Model for every "unit" of data your program manages, and different views displaying this data should share this instance. Your business code manages this object, and whenever this piece of data changes, the GUI is notified using it by firing off some event listeners.

Unsure about using the MVC design pattern

I'm trying to use the MVC design pattern for my project but I'm sort of unsure about how to decouple my program into the classes. The first part of my program is a Login screen which requires the user to enter a their username and password and a start button which checks the details, and there is a button to go to a page where you can add a new user. So I was thinking for my MVC design:
loginpanelView : Just the GUI with the text boxes, labels, buttons etc
loginpanelController:
- implement the actionlistener for the start button here and have a reference to the method checkLogin
- implement actionlistener for add user button here and have reference to a method which switches the panels
loginModel:
- defines the actual method which checks the login
switchpanelModel:
- defines a method which creates a cardlayout system and switches the panels
My understanding is that the controller just makes very general references to what needs to be done i.e. sort of what the user wants to happen, then the model defines the exact method of how to handle this? Would someone mind verifying/ correcting my understanding please? I've read a lot about this design pattern but unfortunately I still don't feel like I have a clear understanding of it. Any help would be much appreciated!
p.s. Sorry! I forgot to include that I'm programming in Java

It sometimes helps to think of MVC in terms of dependencies.
The model repesents what your application does. It has no dependencies on anything. It is what makes your application unique.
The view displays information to the user. This information comes from the model. Therefore, the view has a dependency on the model.
The controller's function is to accept input from the user, dispatch that request to the appropriate model functionality, and (normally) accept the return value and supply it for a view to render. Thus, the controller is usually very tightly coupled to the view(s) that it serves. It also has dependencies on the model.
In this case, the model is your authentication scheme. (In reality, this is not all that much of a model but an entry point in your application, your overall model is something like "process payments", "generate report", "request to create widget", etc.)
You have two views, one to enter authentication information and a second for when an authentication succeeds. The first really does not have any model information, it is solely to collect input (however its design will be based on whatever the authentication model needs, so there is still a dependency here). The second will undoubtedly display a list of available features your application offers or display a landing page etc.
It is the controller's responsibility to mediate these interactions. Therefore, information sent from the first view is received by the controller, dispatched to the authentication model, authentication succeeds or fails, and then the controller chooses the appropriate view to render based on the result.

With such a basic "functional design" it's hard to help you exactly, but you might want to think more about the big picture about what you want.
A user model - database model for a user. Contains a "check login"
method
A login-page View - Form, layout etc
A login controller - Gets the stuff out of the form, tries to log someone in with the method from the user object, and create said user
object
The page view/controllers can be split up ofcourse in several sub-parts, but this might not be a bad place to start.

It seems to me that LoginModel and SwitchPaneModel are not models at all. Model is what you store somewhere. So you will have UserModel and PaneModel. And your controller will implement switchPane method and login method. It's good idea to decouple this method in some separate classes there are lots of methods to perform this task. But I strongly recommend you to find ready solution. Don't invent the bicycle.

A good place to start is here. This is a special case of MVC called Passive View. The first important idea is that the view and the model do not communicate with each other at all. The view only tells the controller about events, and the controller manipulates both the view and the model. A controller can even create new controllers and views (such as for complex modal dialogs). And finally, the model does not communicate with anyone!
So you have the right idea: your loginpanelController listens for button events from the loginpanelView, and then calls the right methods in the model to set the data and validate it.
I think one place you may be having a problem with is switchpanelModel. I don't think you need this. If your loginpanelView is the view with the cards in it, then your loginpanelController should be the one switching the cards.
I think models should be restricted to methods working with its own data, but must have no reference to any GUI element anywhere. Models do not drive the program; controllers do.

Rather then thinking in terms of 'defining' a method, perhaps it is better to think in terms of what is being encapsulated.
For example, loosely, in MVC a view encapsulates primarily the user interface of your program (a login form), a model encapsulates some part of your domain logic (password authentication) and a controller encapsulates the logic that connects a view with a model (it depends there are variation of MVC architecture). The controller is often to some extent coupled to a view (especially if you start adding overtly specific ActionListeners etc) however the model should be quite reusable/exchangable (changing how you validate should not mean you have to change any view/controller that uses it)

GUI guidelines for swing

Is there a resource where GUI design for swing is explained? Like best practices and such.

Design guidelines aren't exactly followed much anymore because Swing works on so many different platforms. Sun wrote up some a long time ago, and never changed them so I'd say read it if you think it will help. Here is some practical knowledge about doing swing development.
Never use GridBagLayout. Grab TableLayout. It radically simplifies layout for you Swing UI. GridBagLayout is the devil.
Don't over embed components just to get a layout right (i.e. embedded BoxLayout, etc). See point 1 for how to do this. There are performance issues having components on the screen.
Separate your program along MVC lines. Swing has View and Model separation, but in large programs the View (i.e. what subclasses a Swing Component) turns into a psuedo View/Controller only making things complicated to reuse and maintain. It turns into spaghetti code fast. Break the habit and create a Controller class that DOES NOT extend Swing. Same goes for the Model (no swing). Controller instantiates high level view classes, and wires itself as a listener to views.
Simplify popup dialogs using simple panels only. Don't subclass JDialog. Create a reusable dialog class that wraps a panel that can be used something like JOptionPane. Your panels will not be tied to dialogs only and can be reused. It's very easy when you work this way.
Avoid actionlistener/command. This is old junk and not very reusable. Use AbstractAction (anon classes are your choice I don't have a problem with them). AbstractAction encapsulates text, icon, mneumonics, accelerators, reusable in buttons, popups, menus, handles toggling enabled/disabled states, can be shared among multiple components, it also is the basis for InputMap/ActionMaps for mapping keyboard strokes to actions. ActionMaps give you loads of power for reuse.
It's best to have to view dispatch events to the controller. I'm not talking about mouse/keyboard junk, but high level events. Like NewUserEvent, AddUserEvent, DeleteUserEvent, etc. Have your controller listen for these high-level business events. This will promote encapsulation by keeping the concerns of the view (should I use a table, list, tree, or something else?) separated from the flow of the application. The controller doesn't care if the user clicked a button, menu, or checkbox.
Events are not just for the Controller. Swing is event programming. Your model will be doing things off the SwingThread or in the background. Dispatching events back to the controller is a very easy way to have it respond to things going on in the model layer that might be using threads to do work.
Understand Swing's Threading rules! You'd be surprised how few people actually understand that Swing is single threaded and what that means for multi-threaded applications.
Understand what SwingUtilities.invokeLater() does.
Never* ever use SwingUtilities.invokeAndWait(). You're doing it wrong. Don't try and write synchronous code in event programming. (* There are some corner cases where invokeAndWait() is acceptable, but 99% of the time you don't need invokeAndWait() ).
If you're starting a fresh project from scratch skip Swing. It's old, and it's over. Sun never really cared for the client like it did the server. Swing has been maintained poorly and not much progress has taken place since it was first written. JavaFX is not yet there, and suffers from lots of Swing's sins. I'd say look at Apache Pivot. Lots of new ideas and better design and an active community.

I have written a list of recommendations here.

In larger swing projects I do partinioning of the app like that:
Have one class per GUI element like JPanel,JDialog etc.
Use a separate package for each screen, especially if you have to implement customized TableModels or other complex data structures
Don't use anonymous and inner classes, implement instead an ActionListener and check ActionEvent.getActionCommand() in there.
EDIT: If you're rather looking for a tutorial or introduction you could start here

Maybe not exactly what your looking for but it won't hurt to take a peek at Java Look and Feel Design Guidelines

You can check the ideas behind FEST - a swing testing framework. It's main site is here and the project is hosted here

You can find some of best practices in chapter 4 of Professional Java JDK6 Edition

I have some guidelines too:
1) Use Maven and seperate your application into modules (view, controller, service, persistence, utils, model). Be sure you put your Swing components and dependencies only in view package, so if you want to change view framework some day, you can just reimplement view module but you can leave your business logic, controllers, etc... intact.
2) Use GridBagLayout because its very flexible and most configurable
3) Use a SwingTemplate (i can give you an example if you want)
4) Create a SwingFactory that creates components so you can reduces the amount of lines of codes since JFrames orso intend to be very large classes...
5) Let the view (JFrame, JDialog, etc...) have a dependency on controllers. Only do validation input on JFrames but then pass parameters to controllers. They will decide which business logic (service, processors, etc...) will be triggered.
6) Use lots of enumerations
7) Always think how your application can change or how it can be maintained. Therefore, use always code against interfaces or abstract classes. (Think abstract)
8) Use design patterns in your application because they provide confort and maintainability of your code. Make for instance all your controllers, services, dao's singleton classes. Make factories (swingfactory, ...) so you have to write less code over and over again.... Use observers so actions can be processed automatically.
9) Test your appliction: Make a choice between: TDD (Test Driven Design) or DDT (Design Driven Testing)
10) Never put any business logic on JFrames, because it is ugly and its not very Model-View-Controller design. JFrames are not interrested on how the data has been processed.
Hope that helps.