New FocusTraversalPolicy Mechanism Does Not Work Well With OO Designs

Question

I would like to complain about the new focus traversal mechanism not working well with object-oriented GUI designs.
Specifically, we have many reusable panel classes that can be swapped in and out of reusable dialog classes. On some of these panels, the default focus traversal is not what is desirable, perhaps because one component on the right side of the window is just slightly higher than a component on the left side, maybe due to the component on the right having a label on top, and so the default focus goes to the component on the right instead of the left. So we have a need to be able to explicitly define the order of components in some panels.
If I try to define a focus traversal policy in the panel's constructor, a NullPointerException is thrown because the panel's focus cycle root is null (the panel has not been added to any dialog or frame yet).
If I try to associate a focus traversal policy at the dialog level, it would have to explicitly reference its child panels' inner components, which would break the encapsulation of the panels. It would also make it hard to have generic dialog classes into which various reusable panel objects can be swapped.
Someone suggested making each panel a focus cycle root. This makes it hard to "break out" of one panel to move on to the next panel in the dialog. Special keys would have to be assigned to try to cycle out, and these keys would have to be different than the normal traversal keys, making them inconsistent and nonintuitive to the user. Also, the focus policy would have to know if the dialog had more than one panel, what order the panels were in to know whether to cycle to the next panel or not, etc. This is a mess.
Does anyone have any idea how to get around these problems? I have tried using a global focus policy with a global hash map of prev/next component key-value pairs, but we are still running into trouble with some deeply nested tabbed dialogs. It's just not possible to always have the focus cycle root in existence at the point where you want to explicitly define traversal between two components, or when you are trying to establish the default component for a panel in a tabbed pane.
Has anyone else run into similar issues?
Robbie Gilbert
[email protected]

Answer 1

I agree completely. One of the popular consultants on this forum stated that the new focus mechanism was more versatile and only a little more complex. I would say it's more than a little complex given the trouble average programmers are having understanding how it works...at least at first...and after understanding it realizing that they are going to have type their fingers off to update their code. Oh, and the dread of maintaining this awful mess.
I'm currently having the same problem as you Robbie. Some of my reusable panels need special tab ordering...that's not usually a problem, in most programming environments, till now. Now I have to go around the world and back just to get my stupid cursor to be in the right place when I hit the tab key??!!! and special key mappings just to get out of a focus cycle...lame.
And how is an IDE graphical designer going to work with this? It's not, that's how...ok maybe if some kind person or company creates a custom focus traversal policy editor of some kind, I don't know.
Good grief Sun! We need something to help us meet our deadlines, not solutions that force us to spend 80% of our time customizing every stinking bit of UI functionality we need!!!
JTables are even worse. I've mastered most of the garbage that is JTable after many months of pain and I don't know how I'm going to help my peers understand them in any short amount of time. Most of them were Oracle Forms programmers, not that that is any great solution either. But they will likely have problems.
In conclusion, I wish I had chosen another UI technology for our new product client, and may yet.