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

[Rich Kulp <richkulp@xxxxxxxxxx>]

Hi, 

Comments in red

Gerald Rosenberg <gerald@xxxxxxxxxx>
Sent by: ve-dev-bounces@xxxxxxxxxxx

06/13/2006 07:39 PM

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

Actually, I was trying to make this just as simple and
plain as possible: adding minimal ordinary support for just one layout
manager.

1) Unfortunately, seems that I am not even talking to the remote VM.  When
I run this code, I am still getting a null assigned to "formLayoutHelperType":

        String targetVMHelperTypeName = "java.lang.String";
 <<<< that should exist in any VM

         formLayoutHelperType = getContainerBeanProxy().getProxyFactoryRegistry().
                  getBeanTypeProxyFactory().getBeanTypeProxy(targetVMHelperTypeName);

The result of the terminal "getBeanTypeProxy()" call is a Command.GET_CLASS_NOT_FOUND.
 Shouldn't I be able to find at least the String.class on the remote
VM?  Any advice on how to debug?

--- RLK You should be able to see string. Is
there any .log file? There may be more errors before this that indicate
the real error.

2) The JGoodies standard forms layout manger has exactly one bean standard-form
property (int[][] get/setGroups()).  Instead, all of the really interesting
values are provided as constructor parameters.  Therefore, was not
planning on having a beaninfo, at least until I can generate/handle synthetic
bean properties on the propertypage.  Not sure that is even possible,
so, for now, just not bothering with a beaninfo.

--- RLK Beaninfo would only be necessary if
you were working with properties or wanted to provide a special customizer
for the class from the property sheet. There are other reasons, but until
you need them, then no need to worry about it.


3) If I follow the standard pattern of exposing the forms.jar -- contributing
the forms.jar used internally by the plug-in to user projects -- I am still
uncertain as to what the container value should be.  

You said that the container value "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."
 Sorry, just cannot parse that with certainty.

The forms.jar contains "com.jgoodies.forms.layout.FormLayout.class",
which is the actual layout manager.
The maximum single path part that will still include all classes in the
forms.jar is "com.jgoodies.forms".
The forms.jar is located in the root directory of my plug-in.
The plug-in has an ID of "net.certiv.ve"

So is this correct: "container=com.jgoodies.forms.FormLayoutContainer"?

If not, what is?  Or, what additional information is needed to compose
a proper container value?

--- RLK Containers are special Eclipse JDT thingey
that you provide. An example of a container is the "JRE System Library"
that JDT automatically adds to your project's classpath. We use containers
to key off of to indicate "ah, we know what this container has
in it, so we need to contribute certain stuff to the editor".
For example, if we see the SWT Container in the classpath, then we know
that SWT is being used and we then contribute the SWT VE stuff. 

The problem here is that the jgoodies forms.jar
is not being put into the classpath via a container, so we don't know that
we need to contribute your special stuff. You can use the JRE container
as a container, but then your stuff will be contributed to ALL projects,
not just ones that have the jgoodies forms jar in the classpath. This may
be ok as long as you don't have any heavy IConfigurationContributor (i.e.
one that does a lot of stuff to the remote vm when contributeToRegistry
is called), or anything else that it does, such as adding listeners or
such. Because these will happen whether there is a forms jar in the classpath
or not.

The important thing is that since you are not
supplying a container for us, the project's buildpath will only see the
jgoodies forms.jar. So the compiler will only see what is in the jgoodies
jar when compiling. And this makes sense because when the user runs their
application outside of VE they will only have the jgoodies forms.jar available.
they won't have any of your jars available at that time because you did
not tell them to use your jar instead.

Now your IConfigurationContributor can put other
jars onto the remote vm's classpath. That is what we do in our JFCVisualContributor
does. The method:

       
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(),
"vm/jfcvm.jar", IConfigurationContributionController.APPEND_USER_CLASSPATH,
true); //$NON-NLS-1$
       
}

does this. It adds the "vm/jfcvm.jar"
to the end of the classpath of the remote vm. The jar comes out of the
org.eclipse.ve.jfc plugin itself (the JFCVisualPlugin.getPlugin().getBundle()
tells us the plugin to get it out of). This jar contains that "auxiliary"
classes that we use. These are the classes that we use doing VE edit time
to do things for us on the remote vm that are too complicated to do through
the proxies. For example, org.eclipse.ve.internal.jfc.vm.JTableManager,
is a class our JTableProxyAdapter uses to get information from the JTable
instance on the remote vm. Things like adding a column to the table. This
can be complicated so we didn't want to do it through proxies only. We
simply call the method in JTableManager through proxies to do the actual
work on the remote vm.



Thanks much,
Gerald


At 11:21 AM 6/13/2006, you wrote:
Hi, 

Your's is not a usual situation. Typically people are supplying both the
runtime jar to compile against and use at runtime, and separate editparts/VE
code and beaninfo. 

First, your forms.jar internal one that your plugin is supplying, does
it have an actual FormsLayout class in it? That could be a problem because
the user would not be putting this jar into their classpath in the project.
They would be putting the external forms.jar. So the FormsLayout from the
external jar is the one that will be compiled against and loaded in the
remote vm, not your FormsLayout class. Is that a problem?

Rich _______________________________________________
ve-dev mailing list
ve-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ve-dev