No, not really. All of the basic concepts
are there, they just moved around. The biggest change is
1) we got rid of the com.ibm.wtp plugin
and merged it into JEM. And we've restructured the
palette to match the GEF
palette.
This link shows these
renames plus palette xmi changes:
http://www.eclipse.org/vep/WebContent/docs/components/core/migration1.1/index.html
2) The next biggest change is BeanProxyAdapter
has been re-written to use IExpressions instead of
direct proxy calls. This
is for performance reasons. They allow us to pipe the entire initialization
process
of all of the proxies
at once to the remote vm without waiting for each call to complete, and
then at the
end to get the results.
Your best bet is to look at BeanProxyAdapter and its subclasses to get
an
idea of what needs to
be done.
I've added comments below.
Gili - There are three down there
that are about the decoders, so you will need to answer those.
Rich
"Janak Mulani"
<janak.mulani@xxxxxxxxx> Sent by: ve-dev-bounces@xxxxxxxxxxx
08/12/2005 12:09 PM
Please respond to
Discussions people developing code for the Visual Editor project
To
"ve-Dev@Eclipse. Org"
<ve-dev@xxxxxxxxxxx>
cc
Subject
[ve-dev] Migrating from VE
1.0.2 to VE1.1
Hi,
Is there a document for migration from VE 1.0.2 to VE1.1?
If not could you please provide information about what to expect.
Has anything changed in the specifications like palette and overrides?
I tried compilation and the following changes were noticed. Some are
syntactic but could you explain the others:
IVisualClassCreationSourceContributor -- This is used in the New Visual Class wizard
IVEContributor -- Actually you should be using IVEContributor1,
IVEContributor is deprecated and going away. IVEContributor1
is what you would use to contribute dynamically to the palette, such
as remove the AWT/Swing categories.
CategoryImpl.getLabel() -- This is deprecated. You should use the migration
guide above and switch to drawers in the palette.
IComponentProxy and getParentComponentProxyHost() -- We don't do this anymore. It was a kludge
that caused problems.
ComponentDirectEditPolicy,
ComponentDirectEditManager,ComponentCellEditorLOcation -- Direct edit has been rewritten. See ComponentGraphicalEditPart
and JavaBeanTreeEditPart for how it
is now done.
VisualComponentLayoutPolicy -- Do you mean "VisualComponentsLayoutPolicy".
If so, it has changed but it is still there.
IDirectEditableEditPart -- See my previous comment about direct edit.
getOrphanChildrenCommand() -- ?? We've always had this, it hasn't change
that I know of.
getTheOrphanChildCommand -- ?? No idea what this is.
BeanDeclModel.constructUniqueName -- Gili will have to answer this
ConstructorDecodeHelper.getParsedTree() -- Gili will have to answer this
AbstractIndexedChildrenDeocderHelper.getIndexedParent() & restore() -- Gili will have to answer this
IRectangleBeanProxy & IPointBeanProxy -- These used to be under awt, but we moved
them up to a general concept.
EditPartRunnable.run() and doRun() -- We used to respond immediately to any changes
that came in through the model (through the Notication
and EMF Adapters), but this won't work because those changes can
come on the non-UI thread and GEF requires everything to be on the
UI thread. So we then did Display.asyncExec. But this causes problems because
we couldn't control when things occurred, it just occurred later. And sometimes
multiple changes would come in and so we would do things like
grab an image more than once.
So we created the concept of a
transaction. A transaction is the period from the start of a change to
the end of a change. A change can come either through the command stack or from
Gili/Sri parsing code changes. We don't want to have the changes responded
to until after the transaction is complete. That way we only do things once
instead of multiple times.
EditPartRunnable is a helper to
do this. Read the JavaDoc for it, and also see how it is used to respond
to changes and to queue things off to the end of the transaction.
CDEMessages.getString()
JavaMessages.getString() -- These classes are basically internal and
shouldn't be used, but getString() is gone because we are using the
new Eclipse way of doing this, which is loading the strings into static variables.
It is a performance enhancement because we aren't doing continual lookups
into the properties bundle.
IVisualComponent.getAbsoluteLocation() -- One of the reasons we had IComponentProxy
was because we need to know who the apparent parent was (an apparent
parent is the parent in the java beans view, versus the true parent,
which we may not even be modeling. An example of this is JFrame content pane.
The apparent parent of the content pane is the JFrame itself, while the real
parent is JRootPane, but we aren't modeling this pane). We needed to know
this because component locations were relative to their real parent. We needed
to know who the apparent parent was so that we could calculate the location
relative to the apparent parent instead. We also needed to know who the apparent
parent was so that if the component had changed, we know to tell the apparent
parent that a new image is required.
This was a hack and caused some
problems. So instead of this concept, we introduced absolute location.
Using the ComponentManager , we automatically calculate the absolute location.
This is the location of the component relative to the top-most component (which
is a awt.Window if in a Window, or the free-form host dialog if the
component is on the freeform and is not a Window). That way we need to calculate
the location of the selection handles around the component we take the
component's absolute location and subtract from it the absolute location
of the apparent parent in the graphical editpart tree. This is done in the editpolices
and so it does not need to be pushed down to the proxy adapter where
it doesn't make sense.
Also, as for the images, we pushed
that over to the remote vm. What happens is that every component that we
have explicitly created has a ComponentManager attached to it. This manager is
told that the component he is managing has changed. He tells a common manager
called the feedback controller. Then at the end of the transaction the feedback
controller walks through all of the components that told it they have
changed, and walks through all of the parents of this components and
sends back to the IDE that all of these components/parents have an invalid
image. Then on the IDE side each component proxy adapter knows if anyone
is listening for new images, so when that component is notified from the
remote vm that a new image is required and anyone is listening, it will create
a new image.
BeanProxyAdapter.fOwnsProxy -- This is an internal member that you should
not be looking at. You should be using the isOwnsProxy() method
instead.