[ve-dev] SWT coding patterns

[Dave Orme <DaveO@xxxxxxxxxxxxxxx>]

All,

Gili and I were talking yesterday about the special problems with supporting
SWT's Dialog in VE.  This discussion led to some thoughts about the general
problem of SWT's special coding patterns and how to support them.  Here are
some thoughts designed to start a discussion about this.  If you totally
disagree, please feel free to do so; that's the purpose of this forum. ;-)

According to the SWT docs, the Dialog class is intended to be used as
follows:

 * public class MyDialog extends Dialog {
 *	Object result;
 *		
 *	public MyDialog (Shell parent, int style) {
 *		super (parent, style);
 *	}
 *	public MyDialog (Shell parent) {
 *		this (parent, 0); // your default style bits go here (not
the Shell's style bits)
 *	}
 *	public Object open () {
 *		Shell parent = getParent();
 *		Shell shell = new Shell(parent, SWT.DIALOG_TRIM |
SWT.APPLICATION_MODAL);
 *		shell.setText(getText());
 *		// Your code goes here (widget creation, set result, etc).
 *		shell.open();
 *		Display display = parent.getDisplay();
 *		while (!shell.isDisposed()) {
 *			if (!display.readAndDispatch()) display.sleep();
 *		}
 *		return result;
 *	}
 * }

It would be a bunch of work to make VE follow this exact coding pattern.
But here's an observation:  

There are three basic coding patterns used with SWT:

1) Create a new component by extending Composite.

2) Create a new component by extending an arbitrary class and providing a
createPartControl() or open() to activate the component's functionality.

3) Create a SWT layout using factory method patterns.  For example, JFace
uses this idea in the familiar:

public Composite createPartControl(Composite parent);

pattern.

We can generalize this for the other two cases (shells and Dialogs) by
adding the following two factory methods:

public Shell createShell(Display parent);

and

public Shell createShell(Shell parent);


The primary difference between option #3 and options 1&2 from a code
generation perspective is that all of your SWT controls will be initialized
into stack variables inside the factory method rather than into instance
methods inside the object.  This design has two side effects:

A) Client code can't get at any of those controls.

B) There are no side-effects of calling the factory method (ie:
createPartControl) if it only modifies variables that are local to itself.
Therefore, the factory method itself can be treated like a SWT component by
the builder similar to the way we currently process JavaBeans with the Use
Bean dialog.


The main question I'd like to discuss is "What subset of functionality makes
the most sense to implement for 1.0?"


Thoughts, anyone?


Regards,

Dave Orme
VEP Project Lead