Always on the quest for efficiency I reconsidered the usability of SWT
FormLayout lately. Although it is one of my favored core layouts with respect to flexibility, I had to recognize that it is only reluctantly used by most of my fellow workers. Proposing it for an appropriate task sometimes actually seems to inflict real physical pain, considering the facial reactions…
Indeed, upon closer examination one have to admit that the usage is at least a bit cumbersome. Not so much the layout itself as the
FormData configuration for each control under its reach. The following snippet shows a simple use case that – well, I will not spoil the enjoyment of finding out by yourself what it does:
Label label = new Label( composite, SWT.NONE ); FormData labelData = new FormData(); label.setLayoutData( labelData ); labelData.top = new FormAttachment( 0 ); labelData.right = new FormAttachment( 100 ); labelData.bottom = new FormAttachment( 100 ); labelData.left = new FormAttachment( 0 );
Of course everyone is able to figure out the functionality of the code. But it really has the notion of actually figuring it out – and I guess this is part of the problem. So how about programming this less verbose but nevertheless more expressive in the following way:
Label label = new Label( composite, SWT.NONE ); attach( label ).atTop().atRight().atBottom().atLeft();
While it is definitely more compact, expressiveness is, at least to some extend, in the eye of the beholder and depends strongly on the metaphor one have of the task at hand. In my imagination
FormLayout basically attachs the control boundaries at certain reference points, i.e. the top side atTop, meaning it always keeps the top side of the control at the upper bound of the parent’s client area.
Or it attachs a control atTopTo another control, meaning the control’s upper side is always aligned to the bottom of the other control. Furthermore a side can be attached to a percentage range from the respective client area bound, which all could be expressed like this:
attach( control ).atLeftTo( otherControl ).fromTop( 20 );
With this mindset I developed a little utility class I called
FormDatas to put the outlined ideas into practice. The class provides a static method
attach to create a new instance of
FormData, which is registered at the control given as parameter. The layout data instance is returned wrapped by a
FormDatas object to enable the fluent interfaces style of the configuration methods1.
Additionally there are overloaded method variants to handle e.g. the notion of margin or alignment. The margin is based on the underlying
Attachment#offset attribute, but actually respects the side of the attachment. Therefore a margin of 5
atRight corresponds to the offset of -5 of an
Attachment that has been assigned to the
FormData#right attribute with a numerator of 100:
attach( label ).atRight( 5 );
is short for
FormData formData = new FormData(); label.setLayoutData( formData ); formData.right = new FormAttachment( 100, -5 );
Alignment is backed by the
Attachment#alignment attribute and uses the corresponding SWT constants. To adjust a control’s top attachment to the center of another control for example use the following code:
attach( control ).atTopTo( otherControl, MARGIN, SWT.CENTER );
And here is yet another scenario that shows how to work with a width hint instead of opposing side attachments:
attach( control ).atTop().atRight().atBottom().withWidth( WIDTH );
It is important to mention that the
FormDatas implementation does not cover all possibilities of
FormAttachment. But as I was able to replace all use cases in a current project, I hopefully managed to meet the more common ones.
From the IDE point of view the best way to integrate the
FormDatas is to configure it as favorite. This way the
FormDatas.attach(Control) method is available via content assist that automatically handles static imports and the like.
If you want to have a look at
FormDatas by yourself there is a GitHub gist containing the implementation. However keep in mind that I did not spent any time on documentation, parameter verification or the like. In this regard the utility is a pretty rough cut version that might evolve over time.
The gist contains the
FormDatas and a JUnit test case, as the implementation is meant to be used in production environment and therfore should be tested.
FormDatas#attach(Control)is basically a factory method. Because of this it might look a bit strange returning actually an instance of
FormDatas. However introducing a new type just for the sake of the fluent interfaces style also seemed a bit odd to me – so if you have a better idea… ↩