[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ve-dev] Read/Write of complex LayoutManager values
|
Hi,
It looks like your are close. This
container="net.certiv.ve.jfc.targetvm.formlayout.RemoteVMAdapter"
needs to be the container that you have
that contains your "runtime" code. It needs to be the container
that supplies the jar that contains the FormLayout class itself. You don't
put your adapter class in that jar, your put your runtime into that jar.
The container is then added to a project
that one of your customers would be developing that would be using your
FormLayout. The finding of the container in a project does:
- Supply the FormLayout class
to the project so that it can be referenced and used (this is done through
the <library runtime=...> of the "org.eclipse.ve.java.core.registrations"
and the org.eclipse.ve.internal.java.core.RegisteredClasspathContainerInitializer
- Tell the VE that FormLayout
is in the project path and that it should add the palette contribution
to the palette, and tells what runtime jar should be added (the runtime=...).
Through the "org.eclipse.ve.java.core.registrations".
- And finally any development
time code that needs to be available to the remote vm (such as your RemoteVMAdapter)
and supplied in a different jar. This jar is not available to clients through
the classpath container. It is only available to the VE through the remote
vm at development time. This is contributed through a proxy contributor.
This can be complicated because the
contributions are spread out, but the format is:
(1) Create the container so that
everthing else keys off of that. This is done through the following extension
points. We will be defining the container org.eclipse.ve.example.PrompterContainer.
First we define the wizard page that
allows customers to add your container to their classpath.
<extension
point="org.eclipse.jdt.ui.classpathContainerPage">
<classpathContainerPage
name="Custom Prompter"
class="org.eclipse.ve.internal.java.wizard.RegisteredClasspathContainerWizardPage"
id="org.eclipse.ve.example.PrompterContainer">
</classpathContainerPage>
</extension>
Next we define the container initializer.
This tells how to initialize the container. By using RegisteredClasspathContainerInitializer
it tells us to use the org.eclipse.ve.java.core.registrations extension
point to get the info:
<extension
point="org.eclipse.jdt.core.classpathContainerInitializer">
<classpathContainerInitializer
class="org.eclipse.ve.internal.java.core.RegisteredClasspathContainerInitializer"
id="org.eclipse.ve.example.PrompterContainer">
</classpathContainerInitializer>
</extension>
Then we provide the definition of the
container. This tells the container initializer to use customwidgets.jar
as the jar to add to the customer's classpath. It should contain only the
runtime code. It also indicates what pallete item to add.
<extension
point="org.eclipse.ve.java.core.registrations">
<registration
container="org.eclipse.ve.example.PrompterContainer"
description="Custom Prompter">
<library runtime="customwidgets.jar"/>
</registration>
<palette
container="org.eclipse.ve.example.PrompterContainer"
categories="palette/javavisualbeanscats.xmi"
loc="last">
</palette>
</extension>
(2) Next provide the design time
remote vm jars, or any other special initialization. This also is keyed
off of the container. In this case if PrompterContainer is in the classpath
we will call the JFCVisualContributor.
<extension
point="org.eclipse.jem.proxy.contributors">
<contributor
container="org.eclipse.ve.example.PrompterContainer"
class="org.eclipse.ve.internal.jfc.core.JFCVisualContributor">
</contributor>
</extension>
And the contributor is. In this case
contributeClasspaths is used to contribute the vm/jfcvm.jar from the org.eclipse.ve.jfc
plugin to the remote vm's classpath. This is a design time jar that is
used on the remote vm at design time. This is where you would contribute
your RemoteVMAdapter.jar.
public
class
JFCVisualContributor extends
ConfigurationContributorAdapter {
public
void
contributeClasspaths(IConfigurationContributionController controller) {
//
Add the visualvm.jar and nls jars to the end of the classpath. This jar
contains the vm stuff
//
needed for doing JVE editing.
controller.contributeClasspath(JFCVisualPlugin.getPlugin().getBundle(),
"remoteVMAdapter.jar",
IConfigurationContributionController.APPEND_USER_CLASSPATH,
true);
//$NON-NLS-1$
}
/*
* @see IConfigurationContributor#contributeToRegistry(ProxyFactoryRegistry)
*/
public
void
contributeToRegistry(ProxyFactoryRegistry registry) {
String lookAndFeelClass =
VCEPreferences.getPlugin().getPluginPreferences().getString(VCEPreferences.SWING_LOOKANDFEEL);
if
(lookAndFeelClass != null
& lookAndFeelClass.length() > 0) {
try
{
IBeanTypeProxy aUIManagerBeanTypeProxy =
registry.getBeanTypeProxyFactory().getBeanTypeProxy("javax.swing.UIManager");
//$NON-NLS-1$
IMethodProxy setLookAndFeelMethodProxy =
aUIManagerBeanTypeProxy.getMethodProxy("setLookAndFeel",
"javax.swing.LookAndFeel");
//$NON-NLS-1$ //$NON-NLS-2$
IBeanTypeProxy lookAndFeelType = registry.getBeanTypeProxyFactory().getBeanTypeProxy(lookAndFeelClass);
if
(lookAndFeelType == null)
{
if
(JavaVEPlugin.isLoggingLevel(Level.WARNING))
JavaVEPlugin.log("L&F
not found: " + lookAndFeelClass,
Level.WARNING);
//$NON-NLS-1$
} else
{
IBeanProxy
windowsLookAndFeelProxy = lookAndFeelType.newInstance();
setLookAndFeelMethodProxy.invoke(aUIManagerBeanTypeProxy,
windowsLookAndFeelProxy);
}
} catch
(Exception exc) {
if
(JavaVEPlugin.isLoggingLevel(Level.WARNING))
{
JavaVEPlugin.log("Unable
to set target VM to L&F"
+ lookAndFeelClass, Level.WARNING);
//$NON-NLS-1$
JavaVEPlugin.log(exc,
Level.WARNING);
}
}
}
}
}
(3) And finally you use provide
the BeanInfo and overrides. This is through the BeanInfo registrations
extension point:
<extension
point="org.eclipse.jem.beaninfo.registrations">
<registration
container="org.eclipse.ve.example.PrompterContainer">
<beaninfo
path="vm/jfcbeaninfo.jar">
<searchpath
package="org.eclipse.ve.internal.jfc.beaninfo">
</searchpath>
</beaninfo>
<!-- Doing java.awt
and javax.swing specifically because there are too many matches that
we don't care about if we did just java and javax.
-->
<override
package="java.awt"
path="overrides/java/awt">
</override>
Rich
Gerald Rosenberg <gerald@xxxxxxxxxx>
Sent by: ve-dev-bounces@xxxxxxxxxxx
06/12/2006 03:18 AM
|
Please respond to
Discussions people developing code for the Visual Editor project <ve-dev@xxxxxxxxxxx> |
|
|
To
| Discussions people developing code for
the Visual Editor project <ve-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
| Re: [ve-dev] Read/Write of complex LayoutManager
values |
|
Rich and Joe -- as always, thanks for the help.
Next problem -- that is, first next problem -- is that I cannot seem to
get my "adapter" class (RemoteVMAdapter) to be recognized on
the remote VM. My "getBeanTypeProxy(targetVMHelperTypeName)"
call is, however, always failing -- returning null. I have verified
that VE is talking to the remote VM, sending a request and receiving a
response. Unfortunately, the response is signalling Command.Get_Class_Not_Found.
Result is the same whether I run the plugin as an exported project
or as an Eclipse application.
The full routine (located within my FormLayoutPolicyHelper)
is:
private boolean getFormLayoutHelperProxy()
{
String targetVMHelperTypeName
= "net.certiv.ve.jfc.targetvm.formlayout.RemoteVMAdapter"; //$NON-NLS-1$
if (isContainerBeanInvalid())
return false;
formLayoutHelperType
= getContainerBeanProxy().getProxyFactoryRegistry().
getBeanTypeProxyFactory().getBeanTypeProxy(targetVMHelperTypeName);
// ^^^^ always returns null
try {
formLayoutHelperProxy = (IBeanTypeProxy) formLayoutHelperType.newInstance();
IMethodProxy setContainerMethodProxy = formLayoutHelperProxy.getMethodProxy(
"setContainer", "java.awt.Container;");
//$NON-NLS-1$ //$NON-NLS-2$
setContainerMethodProxy.invoke(formLayoutHelperProxy, getContainerBeanProxy());
} catch (Exception
e) {
e.printStackTrace();
return false;
}
return true;
}
My "proxy.jars" is set as:
vmAdapter.jar=/net.certiv.ve/vm_bin/
where "vmAdapter.jar" contains the adapter class, "net.certiv.ve"
is the plugin ID, and vm_bin is the output directory specified in build.properties:
output.vmAdapter.jar
= vm_bin/
The vm_bin directory does contain the adapter class file at the right path.
I have also tried adding a registration to the plugin.xml, but with no
success:
<extension
point="org.eclipse.ve.java.core.registrations">
<registration
container="net.certiv.ve.jfc.targetvm.formlayout.RemoteVMAdapter"
description="RemoteVMAdapter">
<library
runtime="vmAdapter.jar"/>
</registration>
</extension>
Not sure that I got the right extension point and container.
Anything more or different I am supposed to do to get the adapter recognized
on the remote VM? Any suggestions on how to further debug this problem?
In the hope that you might have a moment to take a closer look, I have
attached the plugin.xml, MANIFEST.MF, etc project definition files.
--------------------------------------------
Second problem is that I need to be able to use my "FormLayoutPolicyHelper"
from the layout customizer invoked from the menu choice that runs FormLayoutLayoutPage.
Since FormLayoutLayoutPage is run as a ".class" file from
the menu selection, it does not get set with the VisualContainerPolicy.
FormLayoutPolicyHelper, however, ultimately needs the policy.
I am using the current selection's EditPart, as provided through the "handleSelectionChanged"
method of FormLayoutLayoutPage to get the policy:
protected
VisualContainerPolicy getPolicy(EditPart editPart) {
ContainerGraphicalEditPart
gPart = (ContainerGraphicalEditPart) editPart;
FormLayoutEditPolicy
fep = (FormLayoutEditPolicy) gPart
.getEditPolicy(EditPolicy.LAYOUT_ROLE);
VisualContainerPolicy
policy = fep.getContainerPolicy();
return
policy;
Seems to work, but this is the policy relied upon by the "getContainerBeanProxy()"
method, which is used in the first question above (and therefore makes
it suspect). Can you verify that this use/approach is proper? If
not, how do I get the correct policy to set to the FormLayoutPolicyHelper
for use in the layout customizer?
Thanks,
Gerald_______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ve-dev
Attachment:
MANIFEST.MF
Description: Binary data
Attachment:
build.properties
Description: Binary data
Attachment:
plugin.xml
Description: Binary data
Attachment:
proxy.jars
Description: Binary data
