[ve-dev] RE: SWT coding patterns

[Dave Orme <DaveO@xxxxxxxxxxxxxxx>]

I liked your comments, Scott, so I hope you don't mind that I'm copying my
response to the list.  Thanks for the feedback.

> I just took a peek at those posts. Sounds pretty reasonable, 
> but are you creating subclasses of Composite et al or 
> subclasses of jface viewers? Those are jface methods, right?

Actually, I'm trying to think as generally as possible.  So I'm including
JFace but not excluding anything else either (such as our own RCPLite
framework).  So when I wrote:

<quote>
- Always codegen into one of:

public Composite createPartControl(Composite parent);
public Shell createShell(Display parent);
public Shell createShell(Shell parent);
</quote>

I mean it *any* context.  If you're subclassing Composite, then your
Composite's constructor just calls createPartControl(this) in its
constructor.  If you're in JFace, then createPartControl gets used directly.
If you're subclassing Dialog, then open() calls createShell(getParent()).

The observation is that for a minimal GUI builder implementation, supporting
these three methods is all that's needed from codegen.  The rest of the code
generation is just boilerplate code that hooks the appropriate one of these
three methods to the rest of the UI.

Maybe we want to support codegenning into any method.  But for a first step,
it seems easiest to just support the 3 methods above, and handle everything
else through templates.

> The only other gotcha I can think of is that perhaps someone 
> might want to create the instance of the component for use 
> outside of where you might normally call createPartControl et 
> al. There might be some slightly different setup for a viewer 
> vs using the component inside some other larger composite.
> 
> So...
> 
> I would suggest generating an init(parent) method to do the 
> initialization rather than the well-known methods. Then have 
> the default generated well-known methods and constructors 
> simply call init. This gives the caller a choice in how they 
> construct, and if they want to construct differently for 
> something like createShell for the dialog, they can tweak the 
> createShell method without impacting standard initialization 
> that's called during construction.
> 
> Basically one level of indirection buys a lot of flexibility, IMHO.

Actually, you've just described exactly my idea, but just reduced what I'm
calling the well-known method names down to just one: ie: init().  We could
do that.  The advantage would be a single name, which might be less
confusing than reusing createPartControl() from JFace once you understand
the idea behind it.  On the other hand, calling it createPartControl() and
createShell() is immediately recognizable to anyone who has used JFace even
if they don't recognize the underlying idea...

> Note that when I say "tweak", this means one of two things:
> 1) User modifies the generated code (which you know I don't like)
> 2) The tool provides a way to hook the generated methods, 
> similar to the event-to-code connections you could add 
> before/after method calls in VAJ's VCE.

I see the value in that approach.

> BTW: When coding GUIs, I usually recommend to people to 
> always subclass a "panel" like container rather than a 
> "window" like container, as you can then drop your GUI into 
> any bigger GUI. For starters, the bigger GUI could simply be 
> a window or dialog (which only adds the "real" GUI to it), 
> but the same GUI could be dropped into a tabbed pane, wizard, 
> or part of another bigger layout. The only "trick" here are 
> things like menus, but that can be handled via a wee bit more 
> indirection, where the containing window could ask the guy 
> dropped into it if it wants to contribute menus, keys, etc. 
> (Hmmm -- sounds sorta like eclipse ;)

:-)


Thanks for your feedback, Scott.


Regards,

Dave