Revision as of 13:37, 6 December 2010

The plugin.xml file is an important and mandatory part of any plug-in for AIBench/OptFlux.

• All the Operations/Views/Icons/GUIs will be herein declared.
• The only artifact that does not required declaration in the plugin.xml file are the Datatypes.

Global Structure of the plugin.xml file

• The plugin.xml file begins with the declaration of the <plugin start=[value] tag. Here, [value] equals a boolean value (either true or false). We will use false as default. This value is only true for some core plug-ins since they will be loaded first by the plug-in engine.
  • All the information pertaining the plugin will be contained from this level on.
• The plug-in is terminated with the closing tag </plugin>

Global entries

There are three global entries pertaining the information of the plug-in itself:

1. <uid> ... </uid> - the unique identifier of the plug-in. A string that can be used to refer to this plug-in from another.
2. <name> ... </name> - the name of the plug-in. Any String used to be displayed as the name of the plug-in in certain places (plugin manager, logs, etc).
3. <version> ... </version> - the version of the plug-in. This can be used to differentiate between versions and is used by the plugin manager to resolve dependencies.

Sections

After the declaration of the the global entries, there are three sections that can be declared, all of which are optional depending on the contents of our plug-in.

Dependencies

The dependencies section is declared every time that our plug-in requires the use of classes belonging to another plug-in. In this case, each plug-in from which we are using classes should be added as a dependency.

• Begins with the <dependencies> tag
  • Each new dependency is declared inside a <dependency uid=[plugin_uid] /> tag pair. Here the [plugin_uid] is the UID of the plugin that we are depending on.
• It is closed with a </dependencies> tag
• Here is an example:

<dependencies>
     <dependency uid="optflux.core"/>
     <dependency uid="optflux.simulation"/>
</dependencies>

Lifecycle

The lifecycle section only rarely used when we need to change the default behavior of our plug-in.

• It is declared as <lifecycleclass> [path.to.our.lifecycle.class]</lifecycleclass>
• The [path.to.our.lifecycle.class] is the full classpath path of a class extending the PluginLifecycle default class.
• Here is an example of the declaration:

<lifecycleclass>saveloadquit.lifecycle.Lifecycle</lifecycleclass>

• And an example of a lifecycle class, modifying a default behavior:

public class Lifecycle extends PluginLifecycle {

	public void start(){

		Workbench.getInstance().getMainFrame().addWindowListener(new WindowListener(){

			public void windowActivated(WindowEvent e) {}

			public void windowClosed(WindowEvent e) {}

			/**
			 * Overrides default behavior of the main frame.
			 * Launches the quit GUI.
			 */
			public void windowClosing(WindowEvent e) {
				Workbench.getInstance().getMainFrame().setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);
				//find quit
				for (OperationDefinition<?> def : Core.getInstance().getOperations()){
					if (def.getID().equals("saveloadquit.operations.quit")){			
						Workbench.getInstance().executeOperation(def);
						return;
					}
				}				
			}

			public void windowDeactivated(WindowEvent e) {}

        		public void windowDeiconified(WindowEvent e) {}

			public void windowIconified(WindowEvent e) {}

			public void windowOpened(WindowEvent e) {}

		});
       }
}

Extensions

Extension Points

CORE: aibench.core.operation-definition (To declare new operations)

WORKBENCH: aibench.workbench.view (To declare new views or other graphical components)

Adding a new view for a datatype

Adding a new operation icon

Adding a new datatype icon

Adding a custom-made GUI for an operation (override default dynamic generation of input dialog)