Tonis Blog

A while ago, I did a presentation on Explorer Views, the Swing components used to display Node hierarchies. After the talk, Jarda asked me why I didn’t show PropertyPanel. PropertyPanles are “generic GUI component for displaying and editing a JavaBeans™ property or any compatible getter/setter pair for which there is a property editor available”. He told me that they might be used to create forms composed of individual PropertyPanels. I like the idea of having components for editing Properties that don’t require you to do the event handling or data binding, but I’m not sure how to use those PropertyPanels correctly:

Nodes expose Properties of a data object and the Properties View listens for Nodes to display the properties. A generic way of manipulating objects, wonderful… from a developer perspective. Unfortunately end users tend to think that PropertySheets are ugly and hard to use. They prefer nicely designed forms. So in addition to our properties, how do we add a nice form?

Why not use PropertyPanels to design it? The JavaDoc says: “A more efficient approach is to implement Node.Property or pass an existing Node.Property object to the PropertyPanel’s constructor or PropertyPanel.setProperty – thus bypassing the use of reflection to locate the getter and setter.” The problem is, when all I’ve got is a node andI want to design a form with a subset of the Nodes Properties in a specific order, how do I get hold of them?

When I’m in charge of designing the node I might create a named Set for the Form and display all it’s Properties. This way I can control what is displayed. The problem is, that I cannot manually design a Swing form with such a generic approach, because the number and order of properties might change. So I’m again back to a generic ugly Property Sheet.

I could also iterate over the set and get hold of each individual Property I’m interested in by Property name. In combination with BeanNode that’s really simple, except for the ugly loop over the Properties. But there’s nothing to make sure that my properties are really there. Defining their names as static Strings helps a bit, but Properties can still removed or renamed with the Strings left behind.

So should I implement  the Properties in my form (or go for PropertySupport.Reflection) and pass the resulting instance to the PropertyPanel constructor? Then I might end up with two sets of properties, one created by the Node, one by the Form and I don’t think that synchronization with the Property Sheet works with that approach(?).

So in the end I might decide to  to create a MyDataObjectpropertiesProvider to give me methods for accessing the individual Properties and put it in my Nodes lookup. But I’m not sure if the benefits of the PropertyPanel will justify the additional complexity. I guess then I’d rather go for a binding framework like JGoodies instead, which gives me a lot of freedom in designing my form and when to commit the changes.

What do you think?