Reputation: 965
My first problem is: "how do I limit the amount of Swing Actions
(using the AbstractAction
as a base for other actions) when the same actions are used in conjunction with different UI components that are referenced with different Swing JPanel
objects that (seem to have) no direct reference to eachother"?
My second problem is: "how to keep referenced between Actions and UI components when the actionPerformerd() method of the action uses TWO or more different UI component references"? I need ui context within the actionPerformed() method at different places that have no direct relation (well, at least that is what I think).
Let me explain my design concerns I am dealing with...
I have one JFrame which holds all UI logic. This JFrame holds three different references to JPanel logic: a ControlPanel
, a MainPanel
and a StatusPanel
(all extend JPanel).
The ControlPanel
sets up the JMenu and items, the JToolBar items and this JPanel is added to the contentpane with all the approriate Actions installed.
The MainPanel
is where the actual communication with the user takes place. This JPanel holds a CardLayout with a bunch of JPanels inside it.
The StatusPanel
is actually a statusbar dealing with all kinds of text messages coming from differnt JPanels, but processed by a StatusBarManager object. No fancy stuff here, just boring gui stuff.
Now the problem part: I first programmed a bunch of extended AbstractActions
for each action I could think of (not so good idea). Next I programmed an ActionFactory
that hands out an Action
obj for a particulair task, like: ActionFactory.getAction("file.new");
This seems like a better approach because I now can instantiate a FileAction
object for all "file" operations with one difference: the implementation of the actionPerformed()
method. This "seems" a good idea because when I call in a different JPanel
the same ActionFactory.getAction("file.new");
I get the same Action
object returned that already was instantiated before (saves a lot of duplicate objects).
Well this might seem a good idea, I still struggle with the context of the JPanels
. When I select a "card" to display within the MainPanel
using the JMenu
and JMenuItems
, I am in the ControlPanel
ui context only and in the actionPerformed()
method I do not have the MainPanel
context to set the "card" using the CardLayout
of that JPanel.
The same goes for when I am in the MainPanel (pressing a button) and have no context of a StatusPanel.
I have looked at these previous suggestions on stackoveflow, but somehow I can't make the connection. I am missing the clue...
Sort of same Q&A over Actions at SO: here, here, here, here, here, here, here, here, and here .
Some suggested to use a framework for this like the appframework or eclipse rcp or the spring rcp, or others. BUT I prefer to not use any frameworks at all for several reasons other than what is available in the default JVM 6.
I hope someone can shine his/her light over this matter that helps me find a good solution for my problem. Thanks for your help in advance!
Upvotes: 0
Views: 257
Reputation: 36611
I think the main flaw in the design you describe is that the actions work directly against the UI, instead of against a model/controller.
If your action just updates a model, and each view part keeps itself in sync with the relevant part of the model, you avoid those dependencies between one action and several other view components.
This also allows to share the common logic. You move that logic from the action to the model/controller, and the action becomes basically a one-liner (calling that logic).
Upvotes: 3