Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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 >>>>>
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 >>>>>
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 >>>>>>>
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 >>>>
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 >>>>
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"?

Thanks and regards,

Janak

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

Back to the top