Using Modal or Embedded APEs

A single APE form can be used in a context dialog (as in pre-5.3 releases) and in an embedded context such as in the StarTeam JBuilder integration, where the form is implanted in a document window, rather than in a modal dialog.

Prior to 5.3, APEs consisted of a subclass of com.starbase.starteam.starflow.AbstractLauncher, which launched the form and placed it in a dialog, and a subclass of javax.swing.JPanel which implemented the form UI. APEs now subclass com.starbase.starteam.starflow.BasicLauncher instead of AbstractLauncher. BasicLauncher serves a similar function but works with embedded forms as well.

A new subclass of AbstractItemEditor was added to 5.3 also. Whereas the BasicLauncher subclass is the entry point for launching the editor in a dialog, this subclass becomes the entry point for launching editors embedded in a window.

The form still subclasses JPanel (typically), but the Navigator component, which supplies the Next, Previous, OK, Cancel, Apply, and Reset buttons, is no longer added directly to the form.

Instead, BasicLauncher adds the form to a dialog that already contains the Navigator component, while the AbstractItemEditor subclass merely instantiates the form with no Navigator component. No Navigator component is used in the embedded context because StarTeam Cross-Platform Client, rather than the form, has the responsibility of handling those functions.

The following optional element has been added to the .propertyeditor.xml for an APE:

<itemeditor class="com.starbase.starteam.changerequest.ChangeRequestEditor"> <jar name="ChangeRequest.jar"/> <jar name="guicomponents.jar"/> <jar name="starflow-extensions.jar"/></itemeditor>

The jar elements serve the same function as in the javaclass element, and the class attribute of the itemeditor element serves a similar function as in the javaclass element. It identifies the name of the entry point for the APE as an embedded form (it must identify a subclass of AbstractItemEditor).

Back to top