Do implement super's constructors

• See JXLabel Constructors for the discussion

General

Do use the highest abstraction available

• Has-a vs. Is-a (somewhere down the thread which is about binding)

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.

The drawbacks:

• 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)

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.

Exceptions

• the view really is-a type of interface, that is if the interface api is actually meant for usage by client code

<-- This creates the navigation links to :  Home | Help | Index | etc.  -->

SwingLabsImperialRules

<-- this automatically adds a header showing the name of this page -->

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 uniniciated 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.

Swing/X

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.

Exceptions

• 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)

Debates

• Using JXDialogs

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.

Exceptions

• "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.

Debates

• JXStatusBar ready for external review - about in the middle of the thread there's an inset about setXXSize
• SpringLayout and GUI Builders

Do use Action instead of ActionListener

Object Orientation

Do not violate super's contract

General

Do use the highest abstraction available

<-- Your JavaDesktop? article goes here. Please try to include at least one sentence describing this topic. -->

<-- Also please try to include at least one sentence describing where each link goes. -->

<-- Please make sure some other page points to your new article so that others can find it! -->

<-- For more on how to write Javapedia articles please read the WritingArticles? page. -->