Re: [ve-dev] Read/Write of complex LayoutManager values

[Joe Winchester <WINCHEST@xxxxxxxxxx>]

Hi Gerald,

Rich and I are in different time zones.
 He's on the East coast and I'm in the UK (Go England - we're gonna
win the world cup, etc...), so just to keep you on your toes I can answer
e-mail you explicitly address to him and vice versa.  

Two ways to do what you want.  

First is that you do everything on the
IDE VM using IJavaInstance and eGet and so forth to get a bunch of IJavaInstance
objects.  Then for every one you have you can do a BeanProxyAdapter.getBeanProxy(IJavaInstance)
to get the live bean and call methods on it and do casts to IIntegerBeanProxy
and so forth to get your actual objects.

Second is that you're already on the
target VM.  You can then more easily traverse the child components
of the container and get their constraints (from the layout manager presumabely)
and then you get to a point where you want to do something useful on the
IDE VM (i.e. manipulate the model so you can re-gen code) and you feel
you're on the wrong side of a one way fence.

I suspect that you're sort of in the
number 2 land right now.  To the best of my knowledge there is no
way you can just go from an arbitrary object on the target VM, while you
are on the target VM side, and work out what IDE object that works with.
 The API just wansn't built that way.  It was designed so that
you do all your manipulation on the IDE VM with the IJavaInstance objects
which make up the visual editor's graph of GUI objects, and then the target
VM is just a passive observer on that model.  You can retrieve a proxy
to the live target VM object and do stuff to it, but once you cross over
to the target VM you're sort of stuck there - like a science fiction other
parallel universe that you can observe but don't know you're being observed
once you're there.

In your post you write:

>I can figure out which remote components are affected from the constraint
data in the remote VM, but I then need to *somehow* correlate those remote
components to existing local >VE objects that can be used in VE commands
to implement the rewrite.

I suspect that what you're doing here is a bunch of code
on the target VM that figures out what components are effected. What you
will need to do is convert this code from method calls on the target VM
to IJavaInstance.eGet(...) calls and IMethodProxy lookups on the IDE VM.
 The code will be more verbose but what it means is that you will
never lose the link between an IBeanProxy and the target VM object.  Roughly
speaking, if you did something on the target VM like
foo.getBoo();
this would become
IJavaInstance foo;
IJavaInstance boo =  (IJavaInstance) foo.eGet(foo.getEClass().eGetFeature("boo"));
Note that if getBoo() returns a collection rather than
a single object then you'll get an EList (which implements java.util.List)
and you just do a different cast and walk.
The fact that getBoo() became a feature in EMF called
"boo" is done for free and using the BeanInfo reflection rules.
 Explicit BeanInfo classes and .override files can be written to affect
the rules if you don't like the defaults.
Keep walking IJavaInstance as far as you can, because
to make a change this is what is going to be the target of your update
command.  If at anytime you need to get a live value it;s something
like
BeanProxyUtilities.getBeanProxy(IJavaInstance);
All of this stuff is kept as IProxyValue objects which
is a way of making the API calls between the VMs asynchronous.  In
earlier VE releases all of the calls were synchronous but this caused latency
performance issues, so now you get a result back straight away you can
work with.  It gets resolved later and you can add a listener to this
if you need to, but usually you don't need to because the IProxyValue just
becomes the next input to another command so everything gets nicely batched
up.

Hope this helps,

Best regards,

Joe Winchester