I think the big question is what are
you relying on from the settingsAdapter. The proxy adapters should get
everything they need from the model itself. If there is some info that
is required, it should be added to the model. This is so that we can bring
up the proxy model separate from the code gen. This is a performance issue
so that we can start showing things before it is completely parsed.
The proxy adapters are meant to be separate
from codegen and not have access to it. We intended this so that in the
future the model could be brought up in an editor that is not based upon
java code, just upon the EMF model.
PS: By the way, did you have any success
getting the images of your ULCButton on the first start of an editor?
Rich
"Janak Mulani"
<janak.mulani@xxxxxxxxx> Sent by: ve-dev-bounces@xxxxxxxxxxx
12/02/2005 08:37 AM
Please respond to
Discussions people developing code for the Visual Editor project
To
"ve-Dev@Eclipse. Org"
<ve-dev@xxxxxxxxxxx>
cc
Subject
[ve-dev] Questions about
decoder
Dear VE Team,
I would like to understand what happens when a previously saved Visual
Class
is opened.
Since the model is taken from the cache and code is parsed/restored in
a low
prio thread, it seems that not all adapters (like Settings Adapter) are
set
on the objects in the model.
To make it clear, in VE 1.0, decode() calls DecoderHelper's
adaptToCompositionModel in which we set on the child's BeanDecoder a
settings adapter for a feature. In VE 1.0, decode() always preceded the
firing of ProxyAdapter.
We are relying on the value of settingsAdapter in our ProxyAdapter's
applySetting method.
In VE 1.1, while opening a class, since decode() is running in a low
priority thread and the ProxyAdapter code is executed earlier and we run
into trouble.
Could you please sugest a solution?
Also please reply to the question below.
>>> Gili >>>
What is the significance of restore() method of IExpressionDecoderHelper?
What should this method do?
> See AbstractExpressionDecoder.decode(), If there is no cache,
a regular
decode will be driven.
> This implies that the decoder will create/update EMF model elements,
as
well as all the BDM meta information.
> If a cache exists, this implies that the EMF model is already online;
decoders will not change it.
> In this case a restore() is called. A decoder is responsible
to *restore*
its meta information
> to the existing model (e.g., use the IJavaObject already in the model,
attache adapters etc.)
>>>>>>>>>>>>
So the restore() is not supposed to touch the EMF model.
Then for a parent child relation, e.g. panel.add(getULCButton()), should
the
restore() method do the following:
//
get the child bean part from the arguments in the above _expression_
fChildBeanPart
=
decodeArguments((MethodInvocation)getExpression(decodingContent), false);
if
(fChildBeanPart == null) {
throw new CodeGenException("No Child Bean Part");
}