Pollo: Customizability and View Type configuration

Customizability

Pollo can be tailored towards editing a certain type of XML file through the following mechanisms:

These together are combined in a so-called "View Type"

View Types

Right after a file is opened, Pollo shows the View Types Dialog. This dialog contains some predefined view types. A view type defines some properties of the new view to be opened: what schema to use, what display specification to use, and what plugins to use. You can also create a temporary view type by manually selecting the schema and display specification to use.

The predefined viewtypes are specified in the file conf/pollo_conf.xml. The basic definition of a view type looks as follows:
<viewtype>
<name>foo</name>
<description>Foo Bar files</description>

<schemas>
...
</schemas>

<display-specifications>
...
</display-specifications>

<attribute-editor-plugins>
...
</attribute-editor-plugins>

<action-plugins>
...
</action-plugins>
</viewtype>

The element name should contain a unique name for this view type. This name is for internal use, it is not shown to the user. The element description contains the name of the view type as shown to the user. The elements attribute-editor-plugins and action-plugins are optional, the other ones are required.

Defining the schema

The schemas-element contains the definition of the schema to use. Here's an example:
<schemas>
<schema>
<factory-class>org.outerj.pollo.xmleditor.schema.BasicSchemaFactory</factory-class>
<init-param>
<param-name>source</param-name>
<param-value>classpath:/schema/sitemapschema.xml</param-value>
</init-param>
</schema>
</schemas>

The schema defintion consists of a factory class name and zero or more init parameters. The following implementations are available:

It is possible to implement a completely new schema type by implementing the interfaces ISchema and ISchemaFactory.

It is possible to define more than one schema. These schema's will then be chained together. This is functionality that's currently not exploited in Pollo, and remains unverified. In the future, this will allow to combine e.g. XSLT and HTML to edit XSL files containing HTML tags.

Defining the display specification

The display-specifications element contains the display specifications to use. Here's an example:
<display-specification>
<factory-class>org.outerj.pollo.xmleditor.displayspec.BasicDisplaySpecFactory</factory-class>
<init-param>
<param-name>source</param-name>
<param-value>classpath:/displayspec/sitemapspec.xml</param-value>
</init-param>
</display-specification>
<display-specification>
<factory-class>org.outerj.pollo.xmleditor.displayspec.GenericDisplaySpecFactory</factory-class>
</display-specification>

As you can see in the example, two display-specifications are specified. These are chained together: if the first one doesn't know about an element, then the next one is queried about it. Since Pollo can't handle the case that the display specification returns a null, you should always end with a 'GenericDisplaySpecFactory'.

The GenericDisplaySpecFactory can either work in a fixed-color mode, in which case it always returns the same color to use for elements, or it can assign values from an internal color table (in which case the same color is always used for the same element, it is not completely random). For this last one, supply an init parameter called 'use-random-colors' with the value 'true'. To use a fixed color, either specify no parameter to use the default color, or use the parameter 'fixed-color' with as value e.g. '123,233,17' (= the red, green and blue values).

Plugins

In Pollo you can create two types of plugins: attribute editor plugins, that supply custom attribute editors, or action plugins, which add actions to a plugin menu.

If you're interested in creating such beasts, take a look at the Cocoon or Ant examples included in Pollo. The short story is: create both a plugin (implement IAttributeEditorPlugin or IActionPlugin) and a factory for them (implement IAttributeEditorPluginFactory or IActionPluginFactory). Multiple action or attribute editor plugins can be chained. For attribute editor plugins, this means that if the first one returns null, the next one is asked for an attribute editor, and so on. For action plugins, all off the action plugins in the chain will be able to add actions to the plugin menu. Note that API's of these plugins could change in the future. But then again, everything can change in the future.


[Home] SourceForge.net Logo