[robertmazur]

I feel like this is an age-old question, but I have not found good references for best practices when building a Swing desktop app. There's a decade of books and such for how Swing components work. But how about a 50,000 foot view of the suggested structure of a Swing app?

For example, I assume the idea of having a centralized controller for all open windows (JFrames and JPanels) is advisable. If a JPanel component has a state change, it notifies the parent controller in case any other entities in the app need to know.

So my setup, from parent down to label/button components is:
MyDesktop extends JFrame (the Parent, and controller)
-- spawns JInternalFrame
---- spawns JPanel
------ and that JPanel contains the fields, buttons, labels, etc

Now, let say a JPanel contains a JButton for "Process Orders", and has a JLabel as a status box (like to display Processing order 001, Processing order 002...etc). Clicking the button triggers the JPanel to notify the controller to initiate business logic somewhere else (perhaps through another api). What's the suggested setup for the controller to continuously update the JLabel in the JPanel where the button was clicked? Should MyDesktop have a clear shot all the way down to the JLabel so it can do something like?:

MyDesktop.jInternaleFrameName.jPanelName.jLabelNam e.setSet("Processing 001...")

Or should each child (the JInternalFrame, the JPanel) have updateXXX() methods to "call down" to their children to send the text "Processing 001" to eventually make it to the JLabel?

It seems to me that the controller (MyDesktop in this case) shouldn't even know the JLabel exists, and therefore the "call down" approach is the right way. Or, am I just completely off base with the entire approach? Where's the docs and tutorials for how to architect these things?

Thanks,
Rob

[ubiberger]

Hi Rob,

In several large swing applications I used the approach to have one controller per panel. This greatly improves decoupling and makes you think of components instead of call-hirarchies.
In your example you would have a "process orders controller", which is called from with the actionPerformed() of your processOrders button. The controller might register itself on some backend model object and will be informed about processed orders by some event. Each event will make the controller update the label. There's typically asynchronous work involved.
With this approach, creation and destrucion of panels is always combined with creation/destruction of corrsponding controllers and registering/deregistering the controller to the backend model.

Maybe this ideas hepl you.

Happy coding,
Uli