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

[Rich Kulp <richkulp@xxxxxxxxxx>]

"Janak Mulani" <janak.mulani@xxxxxxxxx>
Sent by: ve-dev-bounces@xxxxxxxxxxx

09/28/2005 04:01 PM

Please respond to
Discussions people developing code for the Visual Editor project

To	"ve-Dev@Eclipse. Org" <ve-dev@xxxxxxxxxxx>
cc
Subject	FW: [ve-dev] Migrating from VE 1.0.2 to VE1.1

Dear VE Team,

I have some questions about migration. Please see below:

>>>> RLK >>>>
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

>>>>>

JM:

So this means I should use the migration tool on palette xmi file to convert
it to new format. Is this right?

--- RLK Correct. That is why there is a
migration tool.

>>>> RLK >>>>>
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.
>>>>>>>>

JM:

Does the use of IExpressions within BeanProxyAdapter affect the derived
classes or does it men just the mechanism for invoking methods on VM has
changed and the derived classes are transparent to this?

We had a ULCComponentProxyAdapter like VE's ComponentProxyAdapter which
derives from BeanProxyAdapter.

Could you please give some broad hints as to how the derived classes of
BeanProxyAdapter have benn affected by the changes in BeanProxyAdapter?

--- RLK They are completely affected. You
need to modify to use the new methods. Use
existing proxy adapters that are close to
what you want to do and see how they did it. 
There is no general detail I can give other
than to look at what we did.

>>>> RLK >>>>>
IComponentProxyHost and getParentComponentProxyHost()
  -- We don't do this anymore. It was a kludge that caused problems.
>>>>>>>>>>>>>>

JM:

To which class(es) all the functionality of IComponentProxyHost has been
shifted to? Such as disposeOnFreeForm, instantiateOnFreeForm,
getparentComponentProxyHost, getVisualComponentBeanProxy,
childValidted/Invalidated, refreshImage, invalidateImage etc...

ComponentProxyAdapter used to implement IComponentProxyHost. Now it does
not.
So where has the functionality been shifted to?

I observed that ComponentManager is now implementing IVisualComponent and
ComponentProxyAdapter is delegating its IVisualComponent interface to
ComponentManager.

--- RLK Use ComponentProxyAdapter as a template
of what needs to be done. I'm
sorry but I can't be more specific. It wasn't
moved to any one place. The concept 
is that the ComponentManager on the remote
vm handles notifing parents of
the component that it needs to refresh its
visuals on the IDE side. So each
parent just listens on the component manager
(IVisualComponent) to signal out
that a new image is required. Also all coordinates
are now absolute so that
we no longer need to know who that "semantic"
parent is to determine offsets.
The semantic parent (the parent graphical
edit part) takes the absolute coor
of the child and subtracts its absolute
coor to get the offset of the child
from its origin.


>>>>> RLK >>>>>>>
VisualComponentLayoutPolicy
  -- Do you mean "VisualComponentsLayoutPolicy". If so,
it has changed
     but it is still there.
>>>>>>>>>

JM:

The ctr of VisualComponentsLayoutPolicy now takes a boolean value.

What is the significance of this?

--- RLK : Whether the coordinates are relative
versus absolute. As mentioned
above we use absolute coordinates now.

>>>> RLK >>>>
getOrphanChildrenCommand()
  -- ?? We've always had this, it hasn't change that I know of.

getTheOrphanChildCommand
  -- ?? No idea what this is.
>>>>>>>
JM:

Both these methods are part of ContainerPolicy.

getOrphanChildrenCommand()  is now final

getTheOrphanChildCommand() is a new method.

Could you please explain the significance of these changes?

--- RLK It was made final so that certain
required functions are performed. If it
wasn't final those required
functions could be missed. So the actual
orphan was farmed off
to the new method that is not final. Whenever
you see something
that is final, it is because it is required
function that we can't
afford to be lost. That method will then
farm off to another method
the overridable stuff.
 I don't know anything about
getTheOrphanChildCommand.
I don't have it my code at all anymore.
There is a getOrphanTheChildrenCommand,

which is what getOrphanChildrenCommand delegates
to.

>>> RLK >>>>
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.

>>>>>>>>>>>

JM:

Is this notion of transaction captured only in through method?

Or does it have to be implemented in anyother way in EditPart classes?
Normally, EditPartRunnableAdapter extends EditPartRunnable and this adapter
is set and unset on the model in activate/deactivate methods.

Does anything more needs to be done over and above this to benefit from
the
notion of "transactions"?

--- RLK The EditPartRunnableAdapter is simply
a convienence class that lets
you listen on EMF changes and then cause
those changes to affect the editpart
by queuing it off to the end of the transaction.
The editparts require any
changes to the editpart be done on the UI
thread, but the notifications of
EMF can happen on any thread. We also didn't
want the actual editpart changes
happening until the end of the transaction.
This is because one editpart
could be informed of several changes during
a transaction. By queing to the
end (and only doing it once) then the changes
will happen on the ui thread
and only happen once. We used to use Display.asyncExec
but this allowed the
changes to occur in the middle of a tranaction
and also did the changes multiple
times.

The transaction is automatic. It occurs
when you use the command stack (one
execution of the command stack is one transaction,
no matter how many commands
are executed). And one snippet update from
codegen parsing is one transaction. The
model change controller is used to do the
actual queue up of runnables to run
at transaction end. The EditPartRunnableAdapter
uses this to queue up the requests
it gets.

Thanks and regards,

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

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