Home » Archived » Visual Editor (VE) » VE developer's guide ?
| VE developer's guide ? [message #21530] |
Mon, 01 March 2004 10:05  |
Eclipse User |
|
|
|
Originally posted by: Eugene_Kozlov.exigengroup.com
Hi,
I'm a newbie to VE.
My interests in VE is whether i can create my own MDA visual editor using it
[much like AUIML is].
So is there any developer docs describing this?
What are the benefits of VE comparing to using plain GEF for my purpose?
Thanks,
Eugene
|
|
|
| Re: VE developer's guide ? [message #21708 is a reply to message #21530] |
Tue, 02 March 2004 19:32  |
| Eclipse User |
|
|
|
Hi Eugene,
> My interests in VE is whether i can create my own MDA visual editor using it
> [much like AUIML is].
Eurgene - What is MDA ?
There is actually an AUIML visual editor that is used by the IBM i-series team
to create their markup visually, so I guess if MDA is similar to AUIML then the
answer is yes.
A name that fits the VE better than visual editor perhaps is Graphical Runtime
Builder (or GRUB). GEF is used by the VE and is a great way of interfacing
between draw2D figures and an underlying object model. That model, and how it
creates and notifies the figures are left to each implementation of a GEF
project.
What the VE did was try to abstract out the fact that the object model you are
trying to build for the user is in fact a set of runtime components that make up
a GUI. For this several things are needed
An object model of the GUI elements. This basically consists of representations
of the GUI element, its properties and relationships to other objects. This
runs inside Eclipse and is similar to a DOM. For this VE uses EMF which is the
Eclipse modelling framework.
A metamodel of the GUI elements. The VE currently uses JavaBeans for its Java
implementation, but this can be extended and overridden and we are now for Java
moving more closely to an AST representation.
A target environment that can be used to reconstruct the GUI. This is done
based on the DOM and creating live widgets. For the VE GUI builder an image of
these is taken and shown to the user on a canvas so they can manipulate it and
see it, but a key point is that this is done in a separate process (think JVM
for Java) to the Eclipse IDE so you get insulation of things like classpaths.
Some way of serializing the GUI and re-creating it from the serialized format.
VEP uses .java files that it generates incrementally and parses on open so there
is only one and the latest master copy the user sees or works with. Within the
VEP for Java the coding patterns for generation and parsing are described
externally to the tool and the desire is to have users be able to configure and
extend these to "teach" the tool their patterns and preferences.
All objects used by the VEP such as IPropertySourceAdapter (for the property
sheet), GraphicalEditPart (the GEF viewer), TreeEditPart (the GEF tree view) and
others are instantiated using factory patterns and there is no hard coding in
the ve, so there is a java.core plugin, but all the rules for Swing are in a
java.jfc and for SWT in java.swt. This sort of proves the extensibility API so
new GUI toolkits can be added without intrusion into base code, and new widget
types, etc...
All of these parts can be swopped out, so the desire is that for things like JSF
you can use a separate target VM that is the Browser itself, and for other
languages all you need is a way of getting a metamodel, an instance model, and a
target VM where you can find where GUI things are and what they look like.
Other obvious candidates for the VEP are Java for pervasive devices.
For AUIML they had a Swing rendering engine for the XML, and what they did was
to take the Swing stuff and adapt it so that they used their own serialization
(to and from their XML) but the in-memory object model is the same VEP one, the
metamodel is shared, and they just have specialist classes to deal with the GEF
edit parts and also the interaction with the target VM. Ultralightweight client
from Canoo did a similar thing to extend VEP, so with their product you just
open the base visual editor, have the project configured correctly, and all
their stuff appears on the palette and works correctly with custom code
generation and code to deal with the subtleties of their rendering environment.
> So is there any developer docs describing this?
Not yet. Dave Orme is working on putting these together and has a good blog
(can't recall the URL right now - sorry). Right now we are heads down on SWT
enablement and performance improvements but we do intend to work on a set of
good docs. The other thing is just to ask questions and dig around in the code,
on this newsgroup, and on the VEP mailing list. We're all teccies who love a
good challenge and problem to solve, so talk more about MDA and how it works.
> What are the benefits of VE comparing to using plain GEF for my purpose?
GEF is a great feature and we use it. The difference really is that we have
tried to abstract the problems that any GRUB will face and architect the VEP to
be extensible. A lot of this came from our experience as the team that worked
on the Visual Composition Editor for IBM's Visual Age products (VA Smallalk, VA
C++, VA Java, etc...) and each time a new GUI kit or language or set of widgets
or whatever came up we never had the extensible architecture we'd have desired.
The second system is always the most dangerous one for anyone to work on, and
with the VEP we just spend forever trying to architect it so we wouldn't end up
in the same cul de sac that the VCE got us into.
Best regards,
Joe Winchester
|
|
|
| Re: VE developer's guide ? [message #583035 is a reply to message #21530] |
Tue, 02 March 2004 19:32 |
| Eclipse User |
|
|
|
Hi Eugene,
> My interests in VE is whether i can create my own MDA visual editor using it
> [much like AUIML is].
Eurgene - What is MDA ?
There is actually an AUIML visual editor that is used by the IBM i-series team
to create their markup visually, so I guess if MDA is similar to AUIML then the
answer is yes.
A name that fits the VE better than visual editor perhaps is Graphical Runtime
Builder (or GRUB). GEF is used by the VE and is a great way of interfacing
between draw2D figures and an underlying object model. That model, and how it
creates and notifies the figures are left to each implementation of a GEF
project.
What the VE did was try to abstract out the fact that the object model you are
trying to build for the user is in fact a set of runtime components that make up
a GUI. For this several things are needed
An object model of the GUI elements. This basically consists of representations
of the GUI element, its properties and relationships to other objects. This
runs inside Eclipse and is similar to a DOM. For this VE uses EMF which is the
Eclipse modelling framework.
A metamodel of the GUI elements. The VE currently uses JavaBeans for its Java
implementation, but this can be extended and overridden and we are now for Java
moving more closely to an AST representation.
A target environment that can be used to reconstruct the GUI. This is done
based on the DOM and creating live widgets. For the VE GUI builder an image of
these is taken and shown to the user on a canvas so they can manipulate it and
see it, but a key point is that this is done in a separate process (think JVM
for Java) to the Eclipse IDE so you get insulation of things like classpaths.
Some way of serializing the GUI and re-creating it from the serialized format.
VEP uses .java files that it generates incrementally and parses on open so there
is only one and the latest master copy the user sees or works with. Within the
VEP for Java the coding patterns for generation and parsing are described
externally to the tool and the desire is to have users be able to configure and
extend these to "teach" the tool their patterns and preferences.
All objects used by the VEP such as IPropertySourceAdapter (for the property
sheet), GraphicalEditPart (the GEF viewer), TreeEditPart (the GEF tree view) and
others are instantiated using factory patterns and there is no hard coding in
the ve, so there is a java.core plugin, but all the rules for Swing are in a
java.jfc and for SWT in java.swt. This sort of proves the extensibility API so
new GUI toolkits can be added without intrusion into base code, and new widget
types, etc...
All of these parts can be swopped out, so the desire is that for things like JSF
you can use a separate target VM that is the Browser itself, and for other
languages all you need is a way of getting a metamodel, an instance model, and a
target VM where you can find where GUI things are and what they look like.
Other obvious candidates for the VEP are Java for pervasive devices.
For AUIML they had a Swing rendering engine for the XML, and what they did was
to take the Swing stuff and adapt it so that they used their own serialization
(to and from their XML) but the in-memory object model is the same VEP one, the
metamodel is shared, and they just have specialist classes to deal with the GEF
edit parts and also the interaction with the target VM. Ultralightweight client
from Canoo did a similar thing to extend VEP, so with their product you just
open the base visual editor, have the project configured correctly, and all
their stuff appears on the palette and works correctly with custom code
generation and code to deal with the subtleties of their rendering environment.
> So is there any developer docs describing this?
Not yet. Dave Orme is working on putting these together and has a good blog
(can't recall the URL right now - sorry). Right now we are heads down on SWT
enablement and performance improvements but we do intend to work on a set of
good docs. The other thing is just to ask questions and dig around in the code,
on this newsgroup, and on the VEP mailing list. We're all teccies who love a
good challenge and problem to solve, so talk more about MDA and how it works.
> What are the benefits of VE comparing to using plain GEF for my purpose?
GEF is a great feature and we use it. The difference really is that we have
tried to abstract the problems that any GRUB will face and architect the VEP to
be extensible. A lot of this came from our experience as the team that worked
on the Visual Composition Editor for IBM's Visual Age products (VA Smallalk, VA
C++, VA Java, etc...) and each time a new GUI kit or language or set of widgets
or whatever came up we never had the extensible architecture we'd have desired.
The second system is always the most dangerous one for anyone to work on, and
with the VEP we just spend forever trying to architect it so we wouldn't end up
in the same cul de sac that the VCE got us into.
Best regards,
Joe Winchester
|
|
|
Goto Forum:
Current Time: Tue Jul 15 23:12:47 EDT 2025
Powered by FUDForum. Page generated in 0.05738 seconds |
Home