XML Editor

XAmple XML Editor 2.2. User Manual.

Project Home: http://www.felixgolubov.com/XMLEditor/

Author: Felix Golubov
E-mail: felixgolubov@yahoo.com

1.1. New featurse of the XAmple XML editor introduced in version 2.2
1.2. Area of application.
1.3. XML Schema features.

2. Getting started.

2.1. Distribution.
2.2. Building and running XAmple project.
2.3. Running examples.

3. Customizing XML Schema.

3.1. Default field editors.
3.2. Custom field editors.
3.3. Global field editors.
3.4. Field editor parameters.
3.5. Additional labeling.
3.6. Messages for selected nodes.

4. Underlying tree control - FTree.

1. INTRODUCTION.

        XAmple XML Editor project introduces a java Swing based XML editor that analyzes a given schema and then generates a document-specific graphical user interface. Unlike other XML editors, the XAmple XML editor GUI exposes not just a tree representation of the XML document but rather a logical combination of the XML document and respective XML Schema. The user interface of the XML editor is highly logical and intuitively comprehensible. To be able to prepare valid XML documents of significant complexity, a user is not required to be familiar with XML and XML Schema languages and to have any a-priori knowledge about the documents structural requirements.
        The current version of the XAmple XML editor uses Xerces 2 Java Parser 2.5.0 (see http://xml.apache.org/xerces2-j/index.html), developed under the Apache Software License (see http://xml.apache.org/LICENSE).
    The project currently includes a simple set of XML viewer/editor Swing components (FXBasicView, FXView and FXDoubleView), XML editor data model object FXDocumentModelImpl, sample XML Editor application XAmple and XML editor demo applet FXApplet. FXBasicView Swing component provides all the basic XML viewer/editor functionality. FXView extends FXBasicView with a simple tool-bar; FXDoubleView exposes two FXView components, both of which use the same FXDocumentModelImpl object. A user can edit two different sections of the same XML document without scrolling the whole document back and forth and search a document for certain element/attribute values in one view, maintaining at the same time current position in another view.
        XAmple is a full-blown application and can be used "as is". At the same time XAmple application has been developed mostly as an example of how to use FXDocumentModelImpl and FXDoubleView Swing component. The full source code of the XAmple application is available to the developers without any restrictions for its usage.

1.1. New features of the XAmple XML editor introduced in version 2.2.

When grouping of child elements in a complex element definition is not trivial, XAmple XML editor exposes such an element as a sub-tree, which consists from group-folders, array-folders and child elements. Generally a reconstruction of grouping structures from a sequence of child elements represents a complicated combinatorial problem, which sometimes has multiple solutions. XAmple XML editor v2.2 introduces an entirely new 'reconstruction' algorithm which overcomes all the shortcomings of the previous one (package com.fg.reconstructor). An XAmple XML editor 2.2 distribution package includes a new example Wild-xsd-groups which demonstrates an ability of the XML editor to resolve correctly non-trivial combinatorial problems of reconstruction of hierarchies of XSD groups for given sequences of child xml elements.

1.2. Area of application.

It is easy to notice that XAmple XML editor is not a generic all-purpose XML editor. Being extremely convenient for many types of XML documents, it is much less convenient and even hardly applicable for other types. Specifically, it is not the tool of choice for the language-like XML documents (XHTML, XSLT, XML Schema itself, etc.). At the same time, it is the most convenient tool for all the variety of existing XML configuration files and XML documents, intended for data storage/transportation.
The XAmple XML Editor component is currently intended for two different purposes:

XAmple XML editor can be used as a generic xml-configuration tool, integrated with some major java products (application servers, IDEs, etc.) Currently the process of adding new features to the xml configuration involves development of new versions of some tailor-made configuration tools (xml-generating wizards). Generally it is much less expensive to utilize XAmple XML editor and prepare just a new versions of the XML Schema document when needed.
Usage of an XML editor Swing component component (either of FXBasicView, FXView, FXDoubleView) within a java application provides the application with ability to edit arbitrary set of xml documents of different types. Besides, XAmple XML editing Swing component represents an ultimately flexible schema-driven dialog and thus it can be used as a schema-driven data entry form, etc.

1.3. XML Schema features.

The XAmple XML editor allows editing of the XML documents of quite sophisticated structure. It handles recursive definitions (thus nesting level of elements is not limited), all types of XML Schema grouping (sequence , choice and all groups), nested grouping (when a group can contain other groups), substitution groups, multiple namespaces, etc. At the same time it imposes some restrictions upon the XML Schema syntax. The following XML Schema features currently are not allowed :

anyType unrestricted elements.
any elements.
anyAttribute attributes.
complexType mixed="true" mixed content.

It is easy to notice that all the existing types of the xml-configuration documents and data-holding xml documents are always strictly structured and thus they comply with all the imposed restrictions. Although it is planned to relax these restrictions in the future versions, the XAmple XML Editor will remain being mainly a tool for editing strictly structured XML documents. For custom appinfo schema features see 3. Customizing XML Schema.

2. Getting started.

Download, unpack, rebuild (optionally) and run the XAmple application the way it is explained in 2.1. Distribution and 2.2. Building and running XAmple project sections. After the application window appears on the screen, run the examples from the xml-examples/ directory as it is described in the 2.3. Running examples section.

2.1. Distribution.

After downloading the distribution ZIP file you may unpack it to any directory on your local drive
(to extract files you may use JAR tool: jar xf XAmple-distr.zip)
The distribution file contains a single root directory XAmple-distr with the following content:

doc/ - contains copy of user-manual.html document and javadoc folder.
javadoc/ - a root of the javadoc documentation of the following java packages:

com.fg.custnodes
com.fg.ftree
com.fg.ftreenodes
com.fg.fxapplet
com.fg.reconstructor
com.fg.util
com.fg.xample
com.fg.xmleditor

The most important (and the most thoroughly prepared) is the documentation for the com.fg.xmleditor package, which contains XML Editor components a FXBasicView, FXView and FXDoubleView XML Editor components and FXDocumentModelImpl data model class. The documentation for all the other packages currently is quite sketchy (it will be completed soon). There shouldn't be a problem with the com.fg.xample and com.fg.custnodes packages given that all the source code is available.

lib/ - directory contains following JAR files:

xmleditor.jar - package contains XAmple XML editor classes and components.

xml-apis.jar,
xercesImpl.jar - Xerces 2 Java Parser 2.5.0 package (see http://xml.apache.org/xerces2-j/index.html), developed under the Apache Software License (see http://xml.apache.org/LICENSE).

mdate.jar - a trial version of the MonarchDate Release 1.2.
(The most recent version of MonarchDate can be downloaded from:
http://www.singleton-labs.com/downloads.php . Usage of this package is optional. If you are going to use it you have to buy a license, otherwise just remove mdate.jar from the "lib" directory and FDate component from the "src/com/fg/custnodes" directory and recompile the project)

src/ - directory contains source code of XAmple application (com.fg.xample package) and source code of two custom field editors (com.fg.custnodes package).

xml-examples/ - directory contains a set of sub-directories with different examples of *.xsd (XML Schemas) and respective *.xml files.

The distribution package contains the following files in its root directory:

build.xml - Ant "build" file.
build.bat - calls Ant to compile, build and run the application.
run.bat - runs the XAmple application.
xample.jar - a jar file, which contains compiled classes from the src directory. The file is deleted and rebuilt each time when "build" is executed.

2.2. Building and running XAmple project.

To build and run the application you have to have java version 1.3 or higher installed on your computer. Running the application requires the following jar-files on your CLASSPATH: xample.jar, xmleditor.jar, xml-apis.jar, xercesImpl.jar, mdate.jar (optional). The application main class is com.fg.xample.XAmple.
Since the there is the xample.jar file in the root directory, you can run the project with run.bat immediately without rebuilding it (provided that JAVA_HOME system property is set). If you want to rebuild the project, you can do it by running Ant for "build.xml" (provided that jakarta-ant is installed on your computer) or using any java IDE you like. The Ant build process creates a new classes/ directory, populates it with compiled java classes from the src/ directory, rebuilds the xample.jar file and runs the application.

2.3. Running examples.

In order to execute examples:

Start the XML editor with "run.bat". (Make sure that java 1.3+ is installed on your computer and JAVA_HOME system property is set).
Click "Open XML Schema" button (button #1, marked “XSD”) and select an *.xsd file from any subdirectory of the "xml-examples" directory.
Click "Open XML Document" button (button #2) and select an *.xml file from the same subdirectory you have loaded *.xsd file.
Try to edit XML file, save it, etc. If a sub-directory contains multiple *.xml files, you can load and edit them sequentially without reloading *.xsd file. If you are going to another sub-directory, then you have to load *.xsd file before loading any *.xml files.

The XAmple application maintains a list of previously loaded XSD and respective XML files, which is stored in "history.xml" file in the progect root directory. To reload any previously loaded XSD document or an XML document for current XSD you can choose them from drop-down lists, associated with respective "Open XML Schema"/"Open XML Document" buttons.

a). XML Tree View Modes: Editor and Viewer.

The XML editor exposes 2 tree views, which reside on a split-pane. The width of the left view initially is minimized and the right view covers the whole area. Each view can be set to Editor/Viewer modes (by pressing Editor/Viewer buttons on the view toolbar). A tree view in the Editor mode exposes a hybrid of XML Document and Schema, whereas a tree view in the Viewer mode exposes a real structure of the XML document. Initially the the left view is set to the Viewer and the right one - to the Editor mode.

Optionally, a user can synchronize navigation through nodes of the tree views (by pressing "Synchronized" button on the main toolbar). When navigation is synchronized, a user can add, remove or edit elements in Editor tree view and immediately see changes on Viewer. When navigation is not synchronized, a user can search a document for certain element/attribute values in one view, maintaining at the same time current position on another view.

b). XML tree - folders and leaves.

A tree, which represents XML document consists from folders (tree nodes with child nodes) and leaf nodes. Each folder is provided with an "expansion-bar" - a narrow vertical button, which is located along its left border. A folder can be expanded/collapsed with a mouse click at its expansion-bar. When mouse enters an expansion bar, the XML editor displays respective folder information in a special area.

c). Insertion and removal of elements/groups with multiple occurences.

A tree view in the Editor mode exposes a special type of folders - "array-folders", which contain multiple occurrences of element and group instances. These folders are marked "Array (...) of ..."; their expansion-bars are painted to blue. The XML editor allows insertion and removal of the tree nodes within array-folders only. To insert an element or group node in array-folder, you have to select any existing node within the array-folder and click "Insert before..." or "Insert after..." button or choose a respective item from the pop-up menu. A selected node within an array-folder can be removed with "Remove node" button click.The editor doesn't allow to remove the last node from an array-folder. If Schema-specified "minOccurs" of the respective node is 0, then the whole array-folder can be disabled by unselecting its toggle control (check-box or radio-button - see (e)).

d). Changing an order of element and group instances.

A tree view in the Editor mode allows changing an order of elements and groups within "array-folders" (see (c)) and elements - members of "xsd:all" groups (marked as "Reorderable Group"). To change an order of elements or groups you have to select a respective element/group node and click "Move up" or "Move down" button (or select a respective item from the pop-up menu).

e). Adding and removal of optional elements and attributes.

All the tree nodes on a view in the Editor mode, excluding immediate children of array-folders are provided with toggle controls (check-boxes/radio-buttons). The toggle controls are permanently selected and disabled for the mandatory nodes and enabled for the optional ones. Unselection of the toggle control disables respective node and all its descendants. Disabled (grayed out) nodes are not included in the resulting XML document and are not shown by a tree wiew in the Viewer mode.

f). Choice groups and element substitution groups.

Choice and substituion group nodes are shown only by a tree view in the Editor mode. If a choice group contains neither other groups nor elements with substitution groups, then such a group is represented with a node, which is provided with a drop-down list of available child elements. In this case only one (currently selected) branch is visible at the time. Otherwise all the child nodes of the choice group node are provided with radio-buttons, which constitute an exclusive child selection. An elements with a substitution group is always represented with a node, provided with a drop-down list of substitution elements.

g). Input validation.

The editor verifies validity of element and attribute text values just in time of typing and displays respective error messages. The validity is checked against type, enumeration, minimum and maximum length, regular expression pattern, ID-IDREF referential integrity, etc. All the invalid tree nodes change their colors to red and propagate "invalid" status to their parents - up to the tree root. Any new element node, which can contain other elements appears at first as collapsed and marked as invalid. To make it valid a user has to expand it (and possibly edit values of its children). To find nodes with invalid text values a user may click "Find Invalid Node" button or choose respective item from the pop-up menu.

The example XSD/XML files reside within sub-directories of the "xml-examples" directory. Currently there are 10 examples:

Divisions,
Wild-xsd-groups,
Ejb-jar_1_1,
Jnlp,
Log4j,
TagLibrary,
Xmldbms,
zzz_Application_1_3,
zzz_Ejb-jar_2_0,
zzz_JBoss_3_0,
zzz_Web_app

The Divisions and Wild-xsd-groups examples are my own quite arbitrary but representative ones. All the others represent real configuration examples from the different sources. Currently different examples demonstrate different features of the XML Editor. Here is the list of the XML Editor features and respective examples to look at.

Additional labeling of the elements/groups with information, taken from their descendants – in Divisions, Log4j, Jnlp, Ejb-jar_1_1, Xmldbms.
Multiple namespaces support – in Divisions. Divisions.xsd schema document uses Types.inc schema document, which defines its own namespace. After loading the Division.xsd you may click "New XML" button and choose namespace and root element from the "New XML" dialog.
Custom field editors, declared within "appinfo" elements of the schema document – in Divisions, TagLibrary, Xmldbms. You can find custom field editor definitions within “appinfo” elements of the respective xsd files. Please take a look at the date editors in the Divisions example ({Supervisor or Employee}/Choice group/SequenceGroup #2/ContractStartDate-ContractEndDate). All the field editing check-boxes, editable combo-boxes and text area dialogs in these examples are custom editors.
ID-IDREF referential integrity control – in Log4j. The application provides drop-down lists of available ID values for editing of the IDREF values.
Messages for selected nodes - Divisions, TagLibrary. In “Divisions” example messages are defined for the "Division" elements (in both element and type definitions) and for mentioned above ContractStartDate-ContractEndDate elements. In the “TagLibrary” example messages saying "Fully qualified class name" are defined for "validator-class", "listener-class", "tag-class" and "tei-class" fields. You can easily insert your own messages into “documentation” schema elements for any element, attribute and type definitions.
Regular expressions control during typing - Divisions, TagLibrary. In the “Divisions” example try to edit {Superviser or Employee}/EmployeeInfo/SSN fields. In the “TagLibrary” example try to edit any "*-class" field.
Nested grouping - Divisions (choice groups within "Supervisor" and "Employee" elements contain sequence groups). Since these choice groups contain other groups, they are represented with radio-groups. All the other choice groups in all the examples contain elements and therefore they are represented with drop-down lists.
Substitution group - Divisions ({Supervisor or Employee}/array of < File > elements).
Schema "all" Group - Divisions. It is labeled "Reorderable Group" and resides within {Supervisor or Employee}/EmployeeInfo/EContact elements.
elementFormDefault="unqualified" - Log4j, elementFormDefault="qualified" – all other examples.
Search for invalid nodes - Divisions - Divisions_BAD.xml. This xml file contains 3 errors. Try to load it and click "Find invalid node" button. After each button click the editor shows next invalid node found.
NEW! Wild-xsd-groups example demonstrates a new ability of the XAmple XML editor v2.2 to resolve correctly non-trivial combinatorial problems of reconstruction of hierarchies of XSD groups for given sequences of child xml elements.

The additional labeling (1) and custom editors (3) require additional information, specified within “appinfo” schema elements. The node-specific messages (5) have to be specified within “documentation” schema elements.
The schemas for all the examples but "Divisions" were created from *.dtd documents using XML Spy application. The schemas for the examples with “zzz_” prefix were left "as is", without any additional application-specific information.

The XML editor reads DTD reference from the source XML document and includes it in the resulting XML Document. To allow execution of the examples on computer without Internet connection, all the external DTD references in the XML document are commented out. If you want them to be included, please uncomment them before loading the documents.

If you are going to use XML Spy to create an XML Schema out of existing DTD, please be aware of the following issue. Accordingly the XML Schema Specification, the xsd:restriction has to be used for the restriction of the xsd:anyType to an empty content with a set of attributes, whereas the xsd:extension has to be used for the extension of the xsd:simpleContent with a set of attributes. For some reason the XML Spy uses xsd:restriction in both cases, what is incorrect. You will have to look through the generated schema document and substitute xsd:restriction with xsd:extension when needed.

3. Customizing XML Schema.

Generally, XAmple XML Editor can work with any given XML Schema, having no editor-specific features. Nevertheless customizing the schema with such features increases convenience of the tool and its user friendliness quite radically.

3.1. Default field editors.

By default the component creates and uses 2 types of the field editors:

com.fg.ftreenodes.FComboBox (editable combo-box) - for all the data-types, restricted with xsd:enumeration and for the xsd:IDREF data-type.
com.fg.ftreenodes.FTextField (editable text-field) - for all the other data-types.

3.2. Custom field editors.

Custom field editor is a JComponent or a JDialog which implements com.fg.ftreenodes.ICellControl interface. A custom editor can be specified with appinfo/node-info/@editor-class attribute within any of the xsd:element , xsd:attribute and xsd:simpleType schema definitions. If custom editors are specified for both element/attribute and its type, the element/attribute editor definition will be used. Here is an example of the custom field editor declaration:

<xsd:element name="SomeElement" type="xsd:string">
    <xsd:annotation>
        <xsd:appinfo>
            <fg:node-info editor-class="com.fg.ftreenodes.FComboBox">
          <fg:param>programmer</fg:param>
           <fg:param>engineer</fg:param>
       <fg:param>salesman</fg:param>
         <fg:param>shoemaker</fg:param>
         </fg:node-info>
       </xsd:appinfo>
    </xsd:annotation>
</xsd:element>

If custom editor is a JComponent, it will be placed on the tree node, if it is a JDialog, the tree node will be automatically provided with a button to invoke the dialog.

3.3. Global field editors.

Global field editor is a JDialog which implements com.fg.ftreenodes.ICellControl interface. It has to be instantiated and registered with FXDocumentModelImpl object under some name, for example:

     FXDocumentModel model = new FXDocumentModelImpl();
     FFileDialog fFileDialog = new FFileDialog();
   model.addGlobalEditor("FileDialog", fFileDialog);

A global field editor can be specified with appinfo/node-info/@editor-id attribute within any of the xsd:element , xsd:attribute and xsd:simpleType schema definitions. The Schema declaration has the following look:

<xsd:element name="TextFile" type="xsd:string">
    <xsd:annotation>
        <xsd:appinfo>
<fg:node-info editor-id="FileDialog">
                <fg:param>txt|doc|rtf|Text files: *.txt, *.doc, *.rtf</fg:param>
            </fg:node-info>
</xsd:appinfo>
    </xsd:annotation>
</xsd:element>

Since the global editors are instantiated outside of the XML editor classes, they can hold external object references, etc.

3.4. Field editor parameters.

Parameters for both custom and global field editors are specified with appinfo/node-info/param elements and passed to the field editor components as com.fg.ftreenodes.Params objects. The com.fg.ftreenodes.Params interface defines two access methods: getList() and getMap(). If a param element has a name attribute, it will be inserted into the Map under the given name, otherwise it will be inserted into the List. It is possible to define both List and Map parameters or either of them. If Params object doesn't contain List or Map parameters, then respective getList() or getMap() method returns null.

<xsd:element name="SomeElement" type="xsd:string">
    <xsd:annotation>
        <xsd:appinfo>
            <fg:node-info editor-class="some.fully.qualified.ClassName">
          <fg:param>list-value-1</fg:param>
          <fg:param>list-value-2</fg:param>
          <fg:param>list-value-3</fg:param>
          <fg:param name="name-1">map-value-1</fg:param>
          <fg:param name="name-2">map-value-2</fg:param>
          <fg:param name="name-3">map-value-3</fg:param>
         </fg:node-info>
       </xsd:appinfo>
    </xsd:annotation>
</xsd:element>

3.5. Additional labeling.

Some element and group nodes on the screen can be labeled with the information, taken from some of their descendants (elements and attributes) at any depth. This feature allowes a user to identify tree nodes without expanding them and thus radically simplifies the tree navigation. The mechanism of the additional labeling is following: if some node is specified as "exposed", then its parent node has to show the information, taken from this child along with the information, which was exposed to the child by its children. Any group (xsd:sequence , xsd:choice , xsd:all ) which doesn't allow multiple occurances is considered to be exposed by default, thus all their elements which are specified as exposed will be exposed to the group's parent. An element node which allows multiple occurrences can not be exposed to its parent. A node can be specified as "exposed" with appinfo/node-info/@exposed attribute within xsd:element , xsd:attribute , xsd:simpleType and xsd:complexType schema definitions.

<xsd:element name="category">
    <xsd:annotation>
    <xs:appinfo>
       <fg:node-info exposed="true"/>
       </xs:appinfo>
   </xsd:annotation>
    <xsd:complexType>
        <xsd:sequence>
............................
    </xsd:sequence>
    .............................
    <xsd:attribute name="name" type="xsd:string" use="required">
        <xsd:annotation>
               <xs:appinfo>
                   <fg:node-info exposed="true"/>
               </xs:appinfo>
            </xsd:annotation>
    </xsd:attribute>
...........................
    </xsd:complexType>
</xsd:element>

If some type is specified as "exposed", all the elements and attributes of this type will be considered "exposed" unless they are declared with fg:exposed="false" .

Here is how the additional labeling looks on the screen:

Some nodes from the "xmldbms" example:
    Options DateTimeFormats.Patterns.Timestamp="MM.dd.yy"
    ClassMap ElementType.Name="Customer", ToClassTable.Table.Name="Customers"

Some nodes from the "log4j" example:
    Choice Group category.{name="some.cat", priority.value="TRACE"}
    param name="RemoteHost", value="localhost"
    param name="Port", value="5000"
    param name="LocationInfo", value="true"

3.6. Messages for selected nodes.

Text messages for a node can be specified with appinfo/node-info/@message attribute and/or appinfo/node-info/message elements within xsd:element, xsd:attribute, xsd:simpleType and xsd:complexType schema elements. The respective message will be shown to user when respective element/attribute node is selected.

    <xs:simpleType name="dateType">
       <xs:annotation>
           <xs:appinfo>
                   <fg:node-info message="first line">
                        <fg:message>second line</fg:message>
                        <fg:message>third line</fg:message>
                   </fg:node-info>
           </xs:appinfo>
       </xs:annotation>
       <xs:restriction base="xs:date"/>
    </xs:simpleType>

4. Underlying tree control - FTree.

The basic XML editor component FXBasicView is built on top of custom tree control FTree. This section introduces FTree control and gives a quick overview of its particular features and functionality.

It is easy to notice that the FTree component exposes tree data-structure in a manner quite different from all existing tree controls including JTree. The reason for that is that all existing tree controls are mostly navigational controls with additional data editing functionality. The FTree primarily is a data-editing control.

For the software users the very idea of the screen objects is associated with distinctive screen areas (often rectangular and provided with frames). The software users expect screen objects to alter their appearances depending on the current (enabled/disabled) state. From the user standpoint, a JTree branch can't be seen as a screen object and therefore there is no way to show that the whole tree branch (not just a set of nodes) is enabled or disabled. Alternatively, the FTree component represents data as a tree of nested screen areas - "folders". The folders can be painted in different colors accordingly to their particular purpose and current state. Thus, the FTree component exposes tree branches as distinctive screen objects, which can be enabled/disabled by user. This feature is absolutely crucial for the XAmple XML editor user interface.

The following FTree features are related to "expansion bars" - narrow vertical buttons, which are located along the left border of each FTree folder. An FTree folder can be expanded/collapsed with a mouse click at its expansion bar, unless it is prevented by the user code. Additionally, the FTree component generates special events when the mouse pointer enters and exits expansion bar areas, thus allowing the user code to display any folder-related information. This technique enables the software user to identify any folder at any nesting level and collapse it without scrolling the tree up until the folder label becomes visible. When a folder is collapsed with a mouse click at its expansion bar, the whole tree is scrolled up, so after the folder collapsing the mouse remains pointed at the expansion bar of the same folder (unless the folder is situated too close to the tree top or bottom).

The JTree component represents an extremely flexible framework, which allows to use any kind of field renderer and editors. At the same time JTree provides no help for managing of multiple renderers and editors of different types. Usually it requires a java guru to create new types of renderers and editors and to use different renderers and editors for the different tree nodes. The FTree component addresses these problems and simplifies both creation of the new renderers/editors and usage of multiple renderers/editors of different types. You may notice, that FTree makes possible even creation and usage of previousely unknown editors/renderers, specified with their class names (see 3.2 - Custom field editors ).

You may notice that the XAmple XML editor always uses editors of the same type as respective field renderers. Actually it is not an FTree requirement but rather an XAmple XML editor particular feature. The FTree component allows to use renderers and editors of different types or of the same type with different settings (color, font, frames, etc.).

The FTree is a quite generic component much alike JTree. Generally, it follows all the Swing paradigms:

it supports any custom implementation of the proprietary tree model interface and creates default tree model when no custom model provided,
it uses just a single instance of each type of cell renderer and editor the same way as JTree does, thus sparing a lot of resources,
it generates events quite analogous to JTree events and calls respective listeners,
it has to be placed on a JScrollPane in order to support scrolling, etc., etc.

Like the JTree, the FTree is not a component with completely prebuilt functionality but rather a flexible framework. For example, the tree instance, used by the XAmple XML editor, has the following feature: tree nodes and branches (folders) can be enabled/disabled with mouse click at their associated toggle controls (check-boxes and radio-buttons). This feature is not provided by FTree but implemented with a tree model, custom nodes and specific renderer/editor components.

The FTree is a quite powerful component. It can expose hundreds of thousands of nodes (possibly - of different heights) with multiple sophisticated renderers and editors. The component may represent an attractive alternative to JTree for many types of application.