| Re: [ptp-dev] Problems using org.eclipse.ptp.rm.jaxb.control.ui.widget extension point |
> I'm trying to create a new plugin to implement a custom widget for
> my LSF resource manager. I added an extension for
> org.eclipse.ptp.rm.jaxb.control.ui.widget. I also have dependencies
> listed for the org.eclipse.ptp.rm.jaxb.control.ui and
> org.eclipse.ptp.rm.jaxb.core plugins.
I only have dependencies on org.eclipse.ptp.rm.jaxb.control.ui to be able to get to the custom widget extension point. Make sure you save your MANIFEST/Plugin/build files now to have the rest of the steps below work and find these dependencies.
> I filled in the class name for my control widget and clicked the
> 'widgetClass' string to the left to create the class. I get a dialog
> to create a new Java class where the superclass is Object and
> org.elipse.swt.widgets.Control is listed as an interface.
You might have exposed a small bug. Please write up a bugzilla. The widgetClass' appinfo meta.attribute specifies that the kind is "java" and it is based on ":org.eclipse.swt.widgets.Control" (note the colon) which I think means that it is based upon the interface "org.eclipse.swt.widgets.Control". Oops. So instead I think the metadata should specify "org.eclipse.swt.widgets.Control" (no preceding colon). However, I've not found any documentation yet describing this. Also when I run under Kepler I don't see this error [that is, it works right] which means they might have changed the code to scan all entries and regardless of their order figure out which one is the class and which are the interfaces.
> If I click Finish my class is created, but the declaration is
> flagged since it's coded as implementing Control, which is a class.
Yes, that is expected due to the error above.
> Do I need to specify some class such as Composite (like
> org.eclipse.ptp.internal.ems.ui.EnvManagerConfigurationButton does?
Yes, Control is abstract so you need to specify one of its concrete subclasses typically Composite.
> Also, the constructor for EnvManagerConfigButton has two parameters,
> Composite parent and IWidgetDescriptor wd. I think I need to use the
> same declaration for my constructor, but shouldn't the wizard do that for me?
At this time there is no way to do that in the appinfo meta.attribute specification that I can find. [Where is the doc on appinfo?] But you are correct that you need to specify a two argument constructor whose types are Composite and IWidgetDescriptor. In other words, this ctor is just the way it has got to be and a zero-argument constructor just won't work in this situation.
> If I fill in the class name for the update model class and then
> click the text updateModelClass to the left to create that class
> then I get a dialog to create the class where the superclass is
> Object and an interface
> org.eclipse.ptp.rm.jaxb.control.core.ui.IUpdateModel is specified
Yes, that is expected. That is, in this case appinfo meta.attribute specifies that the kind is "java" and it is based on interface ":org.eclipse.ptp.rm.jaxb.control.core.ui.IUpdateModel". That's the barest minimum.
> If I click finish I get a class where the import statement is
> flagged as unresolvable. I think the import statement should be
> org.eclipse.ptp.rm.jaxb.control.ui.IUpdateModel If I change it to
> that then the import statement is no longer flagged. If I then use
> the quick fix 'add unimplemented methods' the class seems to be
> filled in properly.
I don't know why it is unresolvable, but did you save your MANIFEST/Plugin/build files often?
However, there is a convenience class that implements this interface called org.eclipse.ptp.rm.jaxb.control.ui.AbstractUpdateModel. So you should Browse to and use this class and remove the IUpdateModel interface before you Finish generating you update model class. Nevertheless AbstractUpdateModel is abstract so you'll still need to add unimplemented methods, and the only way is to look at some of the other custom widgets to see what needs to be done.