RE: [ve-dev] SWT coding patterns

[Dave Orme <DaveO@xxxxxxxxxxxxxxx>]

> 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);
>
> <snip/>

I've been thinking about this some more and have begun to think that we can
simplify things quite a bit compared with this proposal (at least for the
purposes of 1.0).  With this new proposal, we should be able to mostly (or
maybe even completely) use our existing codegen structure

In the proposal above, the code generator needs to know about a whole bunch
of new code generation patterns.  But let's make one observation about all 3
of the above:

If we always codegen into a subclass of Composite, then we can also generate
any of the 3 above methods using either our existing code template engine or
our code template engine with minimal modification.

For example, suppose I want to create an Eclipse View using VE.  I would:

Pick File | New | Eclipse View from the menu.

The Visual Class wizard would then generate *two* classes: 

(a) a subclass of Composite (the view's actual UI) and 
(b) the Eclipse View class with createPartControl coded to create an
instance of the Composite subclass we generated in (a).

We then edit (a) in VE just like we do today.  The programmer gets better
modularity by separating the view from its UI and we have to do less work.

The same idea would work for Eclipse editors. 

If we opened up the template API, then any other SWT control or framework
that uses the UI factory pattern could easily extend this mechanism to
support their own frameworks.

Thoughts?  Phil, any issues you see with this from the perspective of the
visual class wizard?


Regards,

Dave Orme