RE: [ve-dev] Methods of BeanProxyAdapter

[Rich Kulp <richkulp@xxxxxxxxxx>]

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

10/28/2005 07:52 AM

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

To	"Discussions people developing code for the Visual Editor project" <ve-dev@xxxxxxxxxxx>
cc
Subject	RE: [ve-dev] Methods of BeanProxyAdapter

Hi Rich,
 
Thanks.
 
Few more questions:
 
 
1. When we drop a ULCButton we
setText to "ULCButton" using the SetPropertyCreationPolicy. The
button show up proprly on the canvas and the free from dialog in the VM
but the property setting for the text property does not seem to happen
on the VM although it is ok in the model (proprty sheet) and code gen.
Only when I add another button to the canvas, the first button's text property
is set on the VM and subsequently visible on the canvas. 
 
Could you please explain why the
setting of property is queued up on the VM? Is there a way to flush the
queue?
 
In our case, even the setting
of other properties in the property sheet is not propogated to the VM,
although it is reflected in the model and code. Only if we add a new widget
to the canvas, the previously set property is set on the bean in the VM
and then canvas reflects the correct picture.

--- RLK I have no idea what a SetPropertyCreationPolicy
is. It is not part of the VE. Unless it is your own implementation of the
CreationPolicy interface. If that is the case take a look at the LabelCreationPolicy.
It does the same thing but for AWT Buttons. The only thing I can think
of is that in your ULCButton proxy adapter you had overridden the "applied"
method and didn't do the necessary things that applied does. That is why
the recommendation is if you need to override (as the javadoc indicates)
is that you should override applySetting or one of the other ones. The
problem is if you override applied it doesn't do the necessary checks that
applied does, nor does it do the revalidate, and without the revalidate
it won't know the image has changed. 

By the way, in the latest 1.2 drivers
the CreationPolicy doesn't exist anymore. We used to have two different
types of creation policies, one used for the palette and one used for the
choosebean. They were redundant. They were combined and moved into the
IContainmentHandler interface. This is called from the JavaContainerPolicy.
 
2. In a variable of type ExpressionProxy,
what should one be looking for to find out the corresponding BeanProxy
it represents on the target VM? Basically how does one examine the _expression_
proxy? what should one look for?

-- RLK What is it you are looking
for? The _expression_ proxy has no idea what the real bean proxy is until
the _expression_ has been invoked. And after it has been invoked the _expression_
proxy is disposed. That is why we add listeners to the _expression_ proxy.
The listeners are called when the _expression_ proxy is resolved to the real
bean proxy at a later time.
 
3. When we put a widget on the
canvas, CompositionProxyAdapter.notifychanged is called. In this method:
a. Create an _expression_ 
b. initSettings - add methods
to be invoked on tgt VM to _expression_ e.g. thru createSimpleMethodInvoke
c. _expression_.invokeExpression
- this is where all the queued up methods in _expression_ are executed. I.e.
- a bean is created on target VM, it is added to free form dialog, and
other properties like visible and location are set on it
 
Is this correct?

-- RLK Basically yes. When a bean
is added to the "components" property it needs to be instantiated.
So all the CompositionProxyAdapter does is create an _expression_ and pass
it to the bean proxy's instantiateBeanProxy(_expression_) method. The bean
proxy adapter will then instantiate itself.
 
4. Now suppose, in the queued
up methods, if one method uses a result from earlier method, how does one
handle this? 

-- RLK That is what the _expression_
proxy is for. You pass in the _expression_ proxy that is returned as the
result of the method _expression_ call into the next method _expression_ call.
It understands what the _expression_ proxy is for and uses the resolved value
in the next _expression_.
 
Regards,
 
Janak
 
 -----Original Message-----
From: ve-dev-bounces@xxxxxxxxxxx [mailto:ve-dev-bounces@xxxxxxxxxxx]On
Behalf Of Rich Kulp
Sent: Thursday, October 27, 2005 7:24 PM
To: Discussions people developing code for the Visual Editor project
Subject: Re: [ve-dev] Methods of BeanProxyAdapter


Hi,

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

10/27/2005 06:30 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] Methods of BeanProxyAdapter

Hello VE Team,

1. In VE 1.0 we used to override the following methods of BeanProxyAdapter:

applied, cancelled, primInstantiateBeanProxy

Will overriding the same methods from BeanProxyAdapter of VE 1.1 have the
same effect? 
--- RLK It depends on what you want to do. Check the javadoc on the methods.
They give explanations of what the methods should do and whether for overridding
you should override a different method. Also, many of your classes are
similiar 
to the standard JFC classes we provide. Check those proxy adapters that
correspond 
closely to your type to see what they do.

If not which methods should be used in their place?

2. In VE 1.0 after using primInstantiateBeanProxy, getBeanProxy() returned
the newly instantiated proxy. Does this still hold?

--- RLK Again you do not have a bean proxy UNTIL the _expression_ has been
invoked. That 
is at a later time. That is why any methods that are passed in an IExpression
should 
use ExpressionProxies. Look at examples of primInstantiateBeanProxy in
other proxy adapters.

3. What is the difference between primInstatiateDroppedPart and
primInstantiateThisPart? Should we be overriding these methods instead
of
primInstantiateBeanProxy? 

--- RLK The difference is that primInstantiateDroppedPart is for all parts
that 
are not the THIS part. The thispart is the one that is being subclassed
in the 
current editor session. You may need to do something different if it was
a 
dropped part instead of a this part.

4. In VE 1.1.0.1 SDK, I am seeing a strange behavior,. When I drop JLabel
on
the canvas, I see a black rectangle i.e. background, although 204,204,204
in
property sheet, is black on the canvas. Explicitly settin the background
color in property sheet is not reflected on the canvas.

--- RLK I don't the answer to this one. 

5. In ComponentProxyAdapter.postInstantiateStuff, VE sets the newly created
beanProxy on componentManager and then adds to freeForm

In the case of ULC VE, I do the following:

                    
                     
       // Get the method proxy to obtain Swing object
underlying a ULCWidget

                    
                     
       IProxyMethod getVisualProxyMethod = TargetVmHelper
                    
                     
                     
                   .getEnvironmentTypeProxy(getBeanProxyDomain())
                    
                     
                     
                   .getMethodProxy(
                    
                     
                     
                     
                     
         _expression_,
                    
                     
                     
                     
                     
         "getVisualComponent",
                    
                     
                     
                     
                     
         new String[] { "com.ulcjava.base.application.ULCComponent"
});

                    
                     
       // Obtain the proxy for Swing object underlying
the ULCWidget

                    
                     
       ExpressionProxy visProxy = _expression_.createSimpleMethodInvoke(
                    
                     
                     
                   getVisualProxyMethod,
TargetVmHelper
                    
                     
                     
                     
                     
         .getEnvironmentTypeProxy(getBeanProxyDomain()),
                    
                     
                     
                   new
IProxy[] { newbean }, true);

                    
                     
       // Set the swing object proxy on component manager

                    
                     
       getComponentManager().setComponentBeanProxy(visProxy,
_expression_,
                    
                     
                     
                   getModelChangeController());

                    
            // Get the method proxy for add
to FreeForm dialog on VM

                    
            IProxyMethod addMethod =
TargetVmHelper.getEnvironmentTypeProxy(getBeanProxyDomain()).getMethodProxy(
_expression_, "addToFreeForm",
                    
                     
                     
  new String[] {"com.ulcjava.base.application.ULCComponent"}
);

                    
            // Add the object to free form

                    
            _expression_.createSimpleMethodInvoke(addMethod,
                    
                     
                     
  TargetVmHelper.getEnvironmentTypeProxy(getBeanProxyDomain()),
                    
                     
                     
  new IProxy[] {newbean}, false);


As you can see, I am calling createSimpleMethodInvoke twice on the same
_expression_. Is this ok?

--- RLK No problem at all. Expressions are meant to have as many method
calls queued up as needed. They 
will eventually be executed in the order you added them to the _expression_.


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