Field editors

Configuration

Detection of the field editors is done when the document editor is started. Each field on the document is checked to see if an editor is available. If no editor is configured the default field editor will be used. This editor is configured based on which field type it is handeling.

When you wish to use a custom field editor you start by creating a configuration file. The file name should be of the format <fieldTypeName>.xml and it should be found in the following directory :

<wikidata directory>/resources/fieldeditors/

The configuration file is expected to contain XML of the following format :

<?xml version="1.0"?>
<fieldEditor xmlns="http://outerx.org/daisy/1.0#fieldeditor"
        class="...">
  <properties>
    <entry key="...">...</entry>
  </properties>
</fieldEditor>

The class property of the fieldEditor element should contain the class name of a class implementing the following interface:

org.outerj.daisy.frontend.editor.FieldEditorFactory

The properties element is optional and can be used to configure the field editor.

Currently the only editor shipped with Daisy is the DefaultFieldEditor. Lets say that you wanted to hard-bind this editor to a field type you'd do it like this : (of course there is no need to do any of this just serves as an example)

Create a file called MyFieldType.xml in the <wikidata directory>/resources/fieldeditors directory with the following content.

<?xml version="1.0"?>
<fieldEditor xmlns="http://outerx.org/daisy/1.0#fieldeditor"
	class="org.outerj.daisy.frontend.editor.DefaultFieldEditor$Factory"/>

This editor will be used next time you edit a document using the MyFieldType field type.

Implementation info

The Daisy document editor is actually a bunch of forms that are implemented using CForms(Cocoon Forms). The fields tab in the editor is just one  such a form. Each field type corresponds with one widget on the form. This means that every instance of the FieldEditor interface needs to generate pieces of form definition and form template. Each generated piece is then aggregated into one big form.

When implementing a new field editor you can extend the AbstractFieldEditor class. When using this method you have to specify methods that return the locations of form definition fragements and form template fragments. If you like you can also specify methods that use stylesheets if you wish to transform the definition before placing it the overall form definition/template. Also you will have to implement a method to load the field value into the form.
The AbstractFieldEditor takes care of the storage, generating form definition/template into correct formats, and generally any other methods the FieldEditor interface expects. Of course it is possible to override these methods with your own implementations. In the JxTemplates that you use to generate the following objects will be at your disposition :

• fieldTypeUse : this is an instance of the org.outerj.repository.schema.FieldTypeUse class.
• fieldTypeUseXml : an xml repesentation of the fieldTypeUse object. This can be used when you wish to generate form fragements based on the field type use using xsl.

Form definition

The form definition shouldn't be too much. Actually this is usually enough. This little blurb of xml will be injected into a fd:group node with id 'field_<fieldTypeId>'.

<?xml version="1.0"?>
<fd:field id="field" xmlns:fd="http://apache.org/cocoon/forms/1.0#definition">  
    <fd:datatype base="string"/>      
</fd:field>

Note that the id of the field is 'field' when using the AbstractFieldEditor keep this id.

Form template

This is a little example of a field editor template.

<ft:group xmlns:ft="http://apache.org/cocoon/forms/1.0#template" 
	  id="field_${fieldTypeUse.fieldType.id}" />
  <tr>
    <td>
      <!-- Field type label -->
	My Field
    </td>
    <td>
      <ft:widget id="field"/>
    </td>
  </tr>
</ft:group>

 Here this blurb of XML is not injected into a group a node so you have to define your own. Note that the id of the group is 'field_<fieldTypeId>'.