Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [ve-dev] SWT code patterns

Title: Message
I got excited when I saw the screen shots below and wanted to see this work for myself.  So I:
 
- Got the latest CVS build from head.
- Deleted the package Gili mentioned in a previous post.
- Created the following class (by hand), inside VE:
 
public class SWTTest {
 
org.eclipse.swt.widgets.Shell shell = null;
 
private void createShell() {
    shell = new org.eclipse.swt.widgets.Shell();
    shell.setSize(new org.eclipse.swt.graphics.Point(640, 480));
}
}
 
If I open VE on this class using the Package Explorer, it chugs for a second or so, then I get a NPE dialog.  When I hand-coded this inside VE, I got nothing...
 
What am I doing wrong?
 
(I'd *love* to do a short, tightly scripted demo of VE for SWT at EclipseCon next week during the VE session.  Not to mention that this is just way cool!)
 
 
Dave
-----Original Message-----
From: Dr Gili Mendel [mailto:gmendel@xxxxxxxxxx]
Sent: Thursday, January 29, 2004 2:43 PM
To: ve-dev@xxxxxxxxxxx; wsjve-dev@xxxxxxxxxxxxxxxxxxxxxx
Subject: [ve-dev] SWT code patterns


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.


.... so we are holding the following first iteration goal assumptions which do not require any VE modeling changes:
  • 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.
  • 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).
  • 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.



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


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.



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

Back to the top