Home | Changes | Index | Search | Go
A collection of general rules to follow when using and designing Swing/X. They are in no particular order, are kind-of FAQ on a higher level then the how-do-I, usually result in hefty debates (by the uninitiated of course [grinning]). They are formulated as imperatives - though there's always a grey zone and special contexts where they might be transgressed. In my experience, those transgressions never pay in the long run: most of the time when I did, I ended up with a sigh "you should have known, idiot!" and fall back to stick to the rule.
todo: follow a proposal from a thread in SwingLabs forum - for all "Don'ts" offer a "Do" alternative.
Do not subclass AWT/Swing/X Components for application needs
All members of the Component hierarchy are designed to be used instead of subclassed. They are tailored to serve a special purpose in a general manner.
- hack around bugs
- need to interfere with the painting - this reason will vanish after full integration of Painters.
- make them play nicely with GUI-Builders (that's from hearsay, not personal experience)
Do not use component.setXXSize
The getXXSize methods must provide reasonable size requirements based on and calculated from the Component's internal state. Explicitly calling setXXSize short-circuits any internal calculation, leaving all burden to return reasonable values on the code which called the setXX. They are used by LayoutManager as hints to balance the actual layout, including locating and sizing the individual components. If one LayoutManager can't cope try a different instead of bullying the component.
- "true" compound components may decide to force sizes of intimate children (an example is JComboBox) - which is not really a transgression because they do take explicit responsibility for the compound component as a whole.
Do not implement model listeners in view classes
Todo: formulate more clearly! The idea is to distinguish "someclass-uses-someinterface" and "someclass-is-someinterface". The former is the case if the view listens to the model to synch internal state. The latter is the case if the view is meant to expose the interface api for usage by client code.
Instead, use a field referencing the listener. To instantiate the field use a factory method. If there is "change expectation", make the factory method protected to allow subclasses to hook into. If the change expectation manifests itself, the field can be made a property.
- the class api is littered with "accidental" public methods (the listener callback methods). Which normally are not meant for usage by client code.
- requires subclassing if modified listener reaction is required (not completely conclusive, the simple stage of the alternative has the same implication, see below)
- the view really is-a type of interface, that is if the interface api is actually meant for usage by client code
Do use Action instead of ActionListener
Do not violate super's contract
Do implement super's constructors
When inheriting from a Swing class to create a SwingX variant implement constructors that appear in the parent unless doing so is counterintuitive. For example, JXLabel should support constructors with the same parameters as JLabel, while JXTreeTable should not implement constructors based on JTable or JXTable, since doing so would not be useful.
Do use the highest abstraction available