Re: [ve-dev] Migrating from VE 1.0.2 to VE1.1

[Rich Kulp <richkulp@xxxxxxxxxx>]

Hi,

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.

Thanks and regards,

Janak


-----------
Janak Mulani
Canoo Engineering AG
web: www.canoo.com
email: janak.mulani@xxxxxxxxx
tel: +91 98200 91274

ULC: Rich Internet Applications for J2EE
www.canoo.com/ulc

_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ve-dev