RE: [ve-dev] SWT code patterns

[Dave Orme <DaveO@xxxxxxxxxxxxxxx>]

Title: Message

This looks like really good start.  I've made a few comments below.

We are in the process of creating a skeleton SWT enabled driver to form the bases from which to build the SWT extensions.   An important part of it is the code generation/parsing patterns that we intend to support.  We need to iterate on this a until we get it right.  The first milestone goal (for the iteration process) is to have a driver that can generate/parse similar patterns to the driver that we have today.  The problem is getFoo() for SWT controls do not make any sense... so we need to move forward a bit. 

I assume here that you mean getFoo() within the context of codegen.  Within SWT controls, SWT properties can either have getters or be public fields.

 .... so we are holding the following first iteration goal assumptions which do not require any VE modeling changes: 

Cool!

•  One will not be able to drop anything but a Shell or a parentless widget (e.g. Dialog) on the Free Form.  If one is to customize a Composite, they will use the create-wizard to  create a class that extends a Composite with a constructor that takes a parent (need to talk more about flags).  The target VM will know how to parent the "this" part on the free form. 

I'm not sure I understand why we'll allow people to drop a shell but not drop a Composite.  Conceptually, both are the same thing: just a container for controls.

 

Is it just technically easier to do it this way?

• Dropping a Shell will produce an instance variable, private org.eclipse.swt.widgets.Shell shell = null,  and a create method private void createShell ()  (private vs. public is tbd).  

Can't we do the same for Composite, but with a create method of:

 

private Composite createCompositeName(Composite parent) {...}

 

Moreover, if you codegen using a factory method syntax, you could conceivably drop any control onto the free form area and use the free form area for editing the factory method.

 

(More on this idea later)

• Dropping a child on a container  will create an instance variable for the child, and reuse the parents initialization method.  ... it will produce the following code/EMF model

Instance variables are created since both the shell and the button are contained in the root membership of the model (vs. a membership owned by a methods element - a local variable).  The "controls" feature denotes the parent/child relationship.  The initializes feature of the methods element denotes that createShell is used to initialize both the shell/button.

This pattern would create a single method per top component. 

I like this code pattern pretty well.  I think it will make for a good first start.

 =======================================================


Note that with bottom up parsing, VE will also recognize the following:




In this case we have the same shell and a button as a child. Both are instance variables, but each is initialized by a different method.
The key here is that createShell() must call the create method of the button.  
 In the case that the createButton() _expression_ is removed from createShell(),  CodeGen will remove the button (and if needed its init method) from the VE EMF model... which implies that the GUI will only show the Shell.  
... this is a first pass to the scenario where as a createButton() exists, but no one (that we can understand) calls it. The WYSIWYG Free Form will reflect that.


This milestone does not take into consideration factory methods. 
 

I think that this is a reasonable approach. 

 

Eventually, I'd like to be able to drag any SWT control out onto the canvas, customize it, and have a factory method generated that can create controls based on those customizations.  Then if that factory method is called in some other layout, have the appropriate control be instantiated.  Like this:

 

private void createShell() {

  shell = new Shell();

  button1 = createButton(shell);

  button2 = createButton(shell);

}

 

private Button createButton(Composite parent) {

  Button result = new Button(parent, SWT.NULL);

  result.setText("Hello, world");

  return result;

}

 

Also, factory methods like this could be recognized as controls in their own right and automatically put on the palette when they are in scope.  ;-)

 

Actually, the code pattern described above is probably a good default.  But it might be nice to have a right-click option on a control: "Refactor -> Extract Factory Method" that makes *any* control into a factory method and puts it in the palette.

 

 

I'm sure you've already thought about the following, but for the record: Shell itself can have a whole bunch of constructor arguments depending on how the Shell is going to be used--as a dialog, as an application main window, etc...  This will need to be addressed eventually, probably by adding the appropriate arguments to createShell() (ie: (Composite parent, int style)) and then passing them to the shell's constructor...

 

 

Anyway, this looks like a great first start!  Good work Gili (and rest of team).

 

The more of this sort of discussion we can get on the list the better.  There's a whole bunch of us out here with a lot of collective SWT coding experience and a few of us with decent SWT GUI builder experience...

 

 

Regards,

 

Dave