[ve-dev] Re: Using JEM to draw cartoon images of widgets (Rich Kulp)

["Namrata" <namrata@xxxxxxxxxxxxxx>]

Rich,

Just to refresh your memory on what we have been discussing.

I have a static model (XML) that I'm representing as EMF model objects.
I want to use the VE components to create an editor for my model. This
editor will be a Swing form editor.

I have made some progress in designing and implementing the solution.
I have my EMF models, and the proxyAdapters.
I have the IDERegistry working. I can create the live visuals in response to
model changes.

Now I want to capture the cartoon image figure to show it in the editor.

Where do I start? I'm looking at ComponentManager class and am a bit
confused about its functionality.

Why does ComponentManager use IExpressions. In my application so far, the
ProxyAdapters can directly
update the live visual using IMethodProxy invokes? Do these changes have to
go through the ComponentManager?

Thanks
Namrata

> --------------------
>
> > Date: Thu, 23 Jun 2005 12:41:58 -0400
> > From: Rich Kulp <richkulp@xxxxxxxxxx>
> > Hi,
> >
> > You shouldn't be looking at anything starting with REM. This is an
> > internal implementation of the IProxy interfaces for remote vm. You
> should
> > be accessing the proxies through the IProxy interfaces.  As I recall you
> > have a well-defined set of visuals and you don't need a java project and
> > extension capability, so you can run using the IDE implementation of the
> > IProxys. This will be much faster foy you because the visuals will not
> > require a remote vm to be started and you won't be forced to be in a
> java
> > project (remote vm proxies require a java project, the IDE
> implementation
> > does not). Look at IDERegistration.createProxyFactory methods.
> > IDERegistration is not internal. But the rest of the IDE... stuff is. We
> > haven't gotton around to making it API yet.
> >
> >
> > REMExpression is an implementation of the IExpression interface. What we
> > used to do was use straight IMEthodPRoxy invokes. This is like calling a
> > method. The problem is that each invoke requires a round-trip to the
> > remote vm. When we built up GUI's this round-tripping added up and
> slowed
> > things down. The expression were used to pipe the invokes to the remote
> > vm. What happens is that we don't wait for us response, we just keeping
> > pushing commands to the remote vm. Then at the very end we do an invoke,
> > and this then waits for all of the previous commands to be invoked and
> > returns results.
> >
> > It turns out though that expressions on IDE proxies is actually slower
> > than using the IMethodProxy invokes. That is because when using IDE
> > proxies, it turns around and calls things directly. This is very fast
> and
> > doesn't have the latency problem that the sockets have that are used
> with
> > the remote vm. So if you are IDE it doesn't require expressions for
> > performance.
> >
> > However, ComponentManager isn't currently written to work without
> > expressions. I see now that it might be a good idea to add calls that
> > don't require expressions. That would make it faster for you using IDE
> and
> > no expressions.
> >
> > Now, the way we connect the EMF model to the live beans is through an
> EMF
> > adapter. This adapter (called BeanProxyAdapter (or BeanProxyAdapter2
> > depending on what driver you have, we just recently renamed
> > BeanProxyAdapter2 back to BeanProxyAdapter) controls the live bean. It
> > hears of changes to the EMF and propagates them to the live beans.
> >
> > You can use something similiar but I don't think it needs to be as
> complex
> > because you have a controlled environment. You don't have to handle a
> wide
> > and undetermined range of beans. Your adapter can simply create the
> > visual, connect it to the ComponentManager, listen for changes, and
> update
> > the visual. The visual should be accessed through the IDE proxies
> because
> > that is what the ComponentManager expects.
> >
> > We also have something called a ModelChangeController. We pipe our
> command
> > stack through this so that only one thread is making changes at time.
> Plus
> > it has a very important added function. You can queue up runnables
> during
> > the execution of the commands that will then be executed at the end of
> the
> > transaction (the command stack execution). This is important because
> > things like grabbing images is expensive, so you don't want to do it
> over
> > and over during the execution of the command because of changes
> happening.
> > So the image grabbing is queued up to the end of the transaction and
> only
> > occurs once.
> >
> > Rich
> >
> >
>