File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Swing / AWT / SWT and the fly likes Design Pattern for enabling/disabling components? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "Design Pattern for enabling/disabling components?" Watch "Design Pattern for enabling/disabling components?" New topic

Design Pattern for enabling/disabling components?

myron schabe

Joined: Aug 21, 2002
Posts: 19
Does anyone know of a design pattern or elegant way of coding the enabling/disabling of components for a large Swing Java Application (i.e. lots of toolbars and menus - that need to be turned off an on depending on where a user is on the screen)?
Many Thanks
Bill Liteplo
Ranch Hand

Joined: Oct 16, 2002
Posts: 88
The complexity of this undertaking depends greatly on the complexity of your interface.
How many windows are we talking about? Fixed set? Arbitrary? How many types of windows? How many types of actions?
Let me explain a bit about what my company's software has done.
Our product interface was somewhat akin to a web browser. You could visit all sorts of content in different locations. Each type of object you could browse had a set of similar actions, but then also aditional actions unique to that object type. Some objects were container-like, which displayed a tree table.
The menus in our menu bars had to be enabled/disabled not only based on what you were looking at, but also on various permissions you have, and (more trickily) what items were selected from (for example) a tree table.
Our original design involved defining Actions that went along with the various GUI-level panes (as opposed to the data cache objects), so that they could be sensitive to GUI issues such as selection. It was easy to make the Actions (and menu items created from them) enable/disable themselves in popup menus, because those were also defined in those classes.
It was harder to hook up these actions to the main menu of the frame. We did this by creating an Actionable interface and some top-level JPanel subclasses that implemented this, and then derived subsequent panes from that. Then, when a user opened a new object, there was a series of calls through each conceptual GUI layer to get the set of Actions, map it to the main menu, and listen for changes in selection (and other events).
This worked for a while but was a little painful to maintain, because we had to provide call-through methods every time we added a GUI layer in between the top-level parent pane and the specific object pane. It was also a pain (pun intended) to hook up user-defined actions written with our plugin API by customers or internally to the main menu.
We later changed to a totally different framework.
First of all, our interface switched to more of a windows explorer/web browser combo (tree on the left, browsable content on the right). The menus had to be sensitive not only to what the selection was, but also where the selection came from.
We implemented a Global Selection Tracker which could be queried for the currently selected object(s), and could be listened to for changes (including active window changes).
We implemented Dynamically Propertied Components, which is a fancy way of saying that you could sum up various properties from various objects together.
Basically, the system uses the GUI containment hierarchy (e.g. one JPanel is parent to another) to go through every component and gather all of its actions.
So instead of being tied through conceptual classes, the actions are delivered to the main menu via global selection tracking and component hierarchy utilization. This system is certainly more advanced to code, but much more flexible and maintainable in the long run, and friendly to user-defined actions.
I wasn't the one who implemented it, so I don't know too much more detail as to how it works.
Hope this gives you some ideas.
Chantal Ackermann
Ranch Hand

Joined: Sep 28, 2000
Posts: 508
the event pattern for GUI state handling is the "State Machine".
Bruce Eckel describes several solutions from simple (= only a little number of states) to more complex and dynamic in his online book "Thinking in Patterns":
myron schabe

Joined: Aug 21, 2002
Posts: 19
Super cool.
Thanks to you both.
I agree. Here's the link:
subject: Design Pattern for enabling/disabling components?
It's not a secret anymore!