Hi Joe:
Thank you very much for the pointers and
insights. I did find the event.mdl Rose model in the JEM SDK and am studying it.
You mentioned there are thoughts of having
an editor for authoring .override files. It seems to me that such an editor is
a good candidate for an exemplary modeling tool for the recently proposed GMF
(Graphical Modeling Framework, http://www.eclipse.org/proposals/eclipse-gmf/index.html)
project.
If you like the idea, maybe I can make the
suggestion to the GMF team and express my interests in contributing to the implementation
of such an editor.
Thanks,
Chaur
From:
ve-dev-admin@xxxxxxxxxxx [mailto:ve-dev-admin@xxxxxxxxxxx] On Behalf Of Joe Winchester
Sent: Thursday, March 17, 2005
2:22 AM
To: ve-dev@xxxxxxxxxxx
Subject: Re: [ve-dev] is there an
ECore model for the override files
Hi Chaur,
I
believe the model is in the package com.ibm.etools.emf.event although Rich Kulp
knows more about this area than me so he might want to jump in and correct me
as I believe this is a temporary place right now. For an element like Add there
is a corresponding Java class as it is a code generated EMF model, so you can
create a workspace, import org.eclipse.ve.swt and its required plugins and then
just open the type "Add" (or "AddImpl") for the class and
then browse it. In the package you will see a file event.mdl and this is
a rose model of the EMF schema.
The
.override files are at the heart of VE extensibility for a particular Java
class. What occurs is that an EMF JavaClass is built up for the class
that contains its structure. The primary source of this is reflection of
the actual class from JDT combined with BeanInfo Introspection, and each
JavaBeans property ends up as an EReference and the hierarchy of the actual
Java class becomes the EMF eSuperclass, etc... Decorators are held
against elements in the model that are used as factory lookup extension points.
For example ClassDescriptorDecorator is held against the JavaClass itself
and holds onto the name of the GEF EditPart names. BeanDecorator holds
onto the name of the adapter that mediates conversation to the target JVM. These
are described in the .override and the best way to learn the syntax is just to
look at the many examples that exist in org.eclipse.ve.jfc or org.eclipse.ve.swt.
There is no hard coding in the base VE code so everything special that an
AWT or Swing or SWT class does is soft coded in either the BeanInfo or the
.override. Some of the .overrides are more complex than others because
things like extra relationships that occur in classes like
javax.swing.JSplitPane or org.eclipse.swt.widgets.TabFolder or
org.eclipse.swt.widgets.Composite need extra relationships and EMF elements.
We
are working hard to document the extension mechanism for this as we get many
requests for how to leverage the .override files. Gili and I gave a
tutorial at Eclipsecon on this very subject where we have a small plugin that
touches a number of the usual extension points (property editors, GEF edit
parts, custom code generation) and this will be made available shortly in the
next few days. We are also working on another example that shows how to
do GUI building using classes that themselves aren't actually visual which is
another popular pattern of extension (it is the one used by Canoo for example
who published a very good whitepaper on the VE web site recently that is
definitely worth reading) and libraries such as JFace would also require this
(for example TextViewer doesn't inherit from Text but you still want to drop a
TextViewer onto an SWT Composite).
For
the .override files we have also toyed around with the idea of having some kind
of fancy editor to hide the complexity of the underlying XML structure, much
the way the PDE has a nice plugin.xml editor that gives you high level pages
with lists and wizards that mean you don't need to code in raw XML syntax. The
amount of work for us to build the editor however might be large so instead
we're trying to document the structure and also possibly think about better
ways to debug mistakes in the files which can be tricky to find just by
trawling through the ErrorLog - possibly a builder could validate some of the
syntax much the way the PDE builder can validate plugin.xml to see that it is
using valid extension points in a correct way over and above being correct XML
syntax.
Best
regards and many thanks,
Joe
Winchester
Please respond to ve-dev@xxxxxxxxxxx
Sent by: ve-dev-admin@xxxxxxxxxxx
To: ve-dev@xxxxxxxxxxx
cc:
Subject: [ve-dev]
is there an ECore model for the override files
Is there an ECore model for the .override files? It seems to
me that there should be such a model to govern the structure of an override
file. Otherwise, how am I supposed to know that there are XML elements such as
<event:Add> and <event:AddMany> to use in an override file? But
when I open an override file, the “event” XML namespace points to
event.xmi, which doesn’t seem to exist anywhere. Any idea?
Thanks,
Chaur
====================
Notice
to Recipient: This e-mail is meant for only the intended recipient of the
transmission, and may be a communication privileged by law. If you received
this e-mail in error, any review, use, dissemination, distribution, or copying
of this e-mail is strictly prohibited. Please notify us immediately of the
error by return e-mail and please delete this message from your system.
Applicable legal notices regarding the e-mail content, attachments, and web
links are posted on Ellie Mae's website.
http://www.elliemae.com/legal.asp
