RE: [ve-dev] SWT coding patterns

[Dr Gili Mendel <gmendel@xxxxxxxxxx>]

blue


------------
Dr. Gili Mendel
IBM
Software Development
RTP Raleigh, NC
(919)543 6408, tie: 441 6408

Dave Orme <DaveO@xxxxxxxxxxxxxxx>
Sent by: ve-dev-admin@xxxxxxxxxxx

07/09/2004 05:15 PM

Please respond to
ve-dev

To	"'ve-dev@xxxxxxxxxxx'" <ve-dev@xxxxxxxxxxx>
cc
Subject	RE: [ve-dev] SWT coding patterns

Now that I've set the stage, here's what I'd like
to propose:

- Always codegen into one of:

public Composite createPartControl(Composite parent);
public Shell createShell(Display parent);
public Shell createShell(Shell parent);

- Have an option to either

A) create all intermediate variables as local variables to the factory
method or
B) create all intermediate variables as private to the class (what we do
now)

It should be possible to change this option on the fly to move all
intermediate variables back and forth between locals and instance variables
private to the class.

One thing that is missing from VE today,
is extra support with Refactoring, 
e.g., the promotion/demotion of instance/local
instances.  There is much that 
is left to be done in this area.

If we're inheriting from Composite, the boilerplate code that we codegen
for
the constructor just calls the createPartControl() method after calling
super(parent, style).

Similarly, if we're inheriting from Dialog, the boilerplate code that we
codegen just calls the createShell(shell) method at the right place inside
the open() method.

This allows us to localize the changes that the code generator has to deal
with to three well-known methods.

Yes... with the new create Wizard dialog
that Phil (Red Hat) have just added, we 
can contribute a SWT Dialog... that will
create the class with the boiler plate, and
we have the initial createShell() method
already set.... some left over of how to set
the Dialog's (this part) style bits etc...

This allows us to work effectively with any third-party framework that
knows
how to deal with JFace's createPartControl() convention.

This allows us to treat the well-known methods as components in their own
right (either in 1.x or in a later version, depending on the schedule we
determine) if they are codegenned with all of their intermediate variables
as local (stack) variables.


Thoughts?

... the more I think about this, I realize
that supporting factories (which we have to do at some point) will require
significance modeling change (impact on
editor/views/codegen).   For v1.0 (hopefully in a few months)... I
think that we may
have to leave the pattern as is today,
and focus on defects/perf.  This will give us time for v1.1 to do
the design iteration/dev. 
for this.

Factories questions for starter
   o How do we know that a factory
method is indeed a factory method ... is it just because it is a "parent"
argument
   o If it is a factory method
 (e.g., createField (Composite parent) which creates a label, textField
and a button), how do we maintain
   model this?  Do have
a bunch of IJavaObjectInatances with loose relationship to a factory method,
or do we introduce a "factory meta instances" which have sub
instances?
   o What about arguments...
a factory may have a String argument to initialize the label.  Do/How
we deal with this?








Regards,

Dave Orme
VEP Project Lead

> -----Original Message-----
> From: Dave Orme [mailto:DaveO@xxxxxxxxxxxxxxx] 
> Sent: Friday, July 09, 2004 3:28 PM
> To: ve-dev@xxxxxxxxxxx
> Subject: [ve-dev] SWT coding patterns
> 
> 
> 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 _______________________________________________
> ve-dev mailing list
> ve-dev@xxxxxxxxxxx http://dev.eclipse.org/mailman/listinfo/ve-dev
> 

_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/ve-dev