Object Editor Guide

Starting the Object Editor

Start the Object Editor with the File -> New -> Object Editor menu item, or using the icon on the main application menubar. The object editor is opened, and a root element object is added to the editor.

When opened, the XMLSchema Editor window appears as below:

Integration Object Editor

The object editor works by using the structure metadata defined in an XMLSchema document, to build the integration objects to map xml documents conforming to the schema into C++/Java objects, and in turn to RDB tables.

This is achieved by starting with an object which binds the root element, and working down through the structure until all elements of interest have been fully bound. The object editor provides the editing facilities to work through the element structure, by interpreting the element structure from the XMLSchema document. In this way, the integration of a schema to C++, Java and RDBs can be constructed in minutes. Once the integration objects have been constructed, these can be used to generate the integration code in the target language.

The object editor can be started in one of two ways – a types editor session and an object editor session.

Types Editor

Since type objects are used in element objects (see below), it is necessary to construct any type integration objects before they are used in the construction of element integration objects. Start a types editor session by clicking on the icon on the main application menubar. The types editor is started for the selected schema document. Note that the types editor can be run concurrently to using the object editor (which will automatically refresh any types used).

Element Object Editor

The object editor is used to construct the element object binding for a valid schema definition. This window is similar to the types editor, but without the schema types pane. When started, the root element object is automatically added to the editor. This forms the starting point for constructing the integration objects for the entire schema.

Editor Window Panes

Schema Types Pane

The types editor includes a schema types pane, which lists the types defined in the schema definition. This holds a tab for complex types, and a tab for simple types. In order to add a type object, select the type name and click the Add button. This populates the object in the Integration Objects pane.

Types Editor – Types Pane

Integration Objects Pane

The object editor displays the currently defined integration objects in the Integration Objects pane. Any type or element objects added to the editor are displayed in this table (non-editable). This table shows the object name and a status field. When the object is not fully bound, a status of incomplete is displayed. When fully bound, the status field is blank. Objects can be deleted by clicking the delete icon right of the status field.

Object Editor – Integration Objects Pane

Editor Pane

Editing of type or element integration objects is done through the Editor pane. When an object is selected in the integration objects table, the object data/properties are displayed in the editor pane.

Object Editor – Editor Pane, with Add / Expand / Remove edit buttons

The editor pane comprises a table used to display and edit the object data, and edit buttons to add, expand or remove object data.

The object table displays the object data under the following columns:

Object Icon	An icon is displayed if the data item is another element object
Object Data	Name of the element object / data item red – element is repeatable (can occur more than once) blue – data is an attribute italics – element / attribute is optional
Type	Type of the element object (if applicable), or data item
Typeset checkbox	Displayed if a type object is defined for this type
Status	undefined if type not set or element object not added to integration objects

The edit buttons below the object table are used to define the object data. The user can add a selected element row as a new element object, expand the selected element to expose its content, or remove the element row entirely.

	Add selection as a new element object
	Expand element (replaces selected element with its content)
	Delete selected element from object

Building Integration Objects

Adding a type object

Types integration objects can be added to the types editor by selecting the schema type in the schema types pane, and clicking the Add button. The type object is then visible in the integration objects table, along with the status. If the status is incomplete, select the object and use the object editor to complete the binding (see below).

Adding an element object

Element objects are added by using the object editor table. The user is faced with a choice when building an integration object – either expand the object element which will replace the selected element with its content (see below), or add the selected data element as a new element object.

When an element is added as a new element object, the object is added to the integration objects table. To see the effect of adding an element object, see the diagrams below.

1. The object editor below shows the shipTo element selected in the object data for the purchaseOrder integration object. Click the Add Element button…

2. The object editor below shows the shipTo element has been added as an integration object, and the status of the shipTo element is now defined.

Expanding an element object

The definition of an integration object can proceed by expanding element data. This replaces the selected element with its content. If the element content is only data (or elements holding only data), the result of expanding the element will be to full define that element. To see how expanding an element data works, consider the example below.

1. The object editor below shows the customer_1 element selected in the object data for the purchaseOrder integration object. Click the Expand Element button…

2. The object editor below shows the customer_1 element replace with its content, resulting in 4 additional data members (prefixed with customer_1_…) in the first 4 rows:

Removing an element object

If element data is not required to be bound in the integration object, the data can be deleted. Select the element/data row in the object table and click the Delete Object button.

Loading type templates

In order to reuse the integration object definitions for any schema types previously defined in the types editor, the template file holding the types can be loaded to the edit session. Types templates are loaded with the Load Types Template button in the editor menubar. This displays the Types templates files dialog – add / remove any template file paths.

If a types template file is edited while loaded into an editor session, the editor session will automatically refresh usage of any type objects from the template file. Any integration objects rendered incomplete from the update will be automatically displayed (eg. if a type object is removed from the loaded template). Any additional type objects will be imported and any associated type checkboxes will be refreshed.

Importing object from another template

In order to reuse the integration object definitions for any schema elements previously defined in another editor template file (for the same schema), load the template file to the edit session. Template files are loaded with the Import Objects button in the editor menubar. Click the Import Objects button and select the template file path using the filechooser dialog displayed.

Saving edits to a template file

An object editor session can be saved to a template file by using the conventional File -> Save / Save As menu items or buttons, and set the destination directory using the filechooser dialog. This will save the edit session for later reuse into a file with a .mxt extension. These templates files can then be re-opened to continue editing, or loaded into another editor session in order to reuse / import integration objects.

Generating integration code

When the integrations objects for a schema definition are fully defined (the schema is fully bound), the integration code for the schema can be generated from the editor session. If any types templates were used, the code generation for these templates must first be carried out from a types editor session for each template used.

The code generation dialog

The code generation dialog appears as below:

Object Editor – Code Generation dialog

The fields populated in the code generation dialog are different for the target language selected. The above diagram illustrates the dialog for RDB (relational database) code generation. This requires extra fields than the C++ or Java code generation, and there will be fewer fields displayed for these languages. The meaning of the fields is described below:

Sql Terminator	Select the sql termination code for the RDB system used
VARCHAR size	Default VARCHAR size for string type data This size can be customized for each table used with the customize dialog.
Package Name	The Java package name used (Java and RDB code only)
Project	The Project name – this mandatory field is used as a prefix for all generated code modules, and should be set to a meaningful project name.
Destination	The directory where generated code files are placed.
Datatypes	Native – use the native types for the target language String – default all datatypes to string
Namespace Prfx	Set the namespace prefix used in instance documents. Select the Default checkbox in order to use the namespace declarations from the schema document.

C++ code generation

Code generation in C++ will generate a series of C++ source modules which implement xml binding of instances of xml documents which conform to the schema document used.

Modules generated from the types editor must be compiled into a C++ library, prior to compilation of the source modules for an object editor template. Sample makefiles are provided for this purpose.

The resulting source modules provide a high-level API to xml integration. These can be used to read and write xml documents to/from C++ objects in memory. These can then in turn be used to integrate with enterprise systems in C++

Java code generation

Code generation in Java will generate a series of Java source modules which implement xml binding of instances of xml documents which conform to the schema document used.

Modules generated from the types editor must be compiled into a Java jar archive, prior to compilation of the source modules for an object editor template. Compile the objects templates also to a jar file. Sample makefiles are provided for this purpose.

The resulting source modules provide a high-level API to xml integration. These can be used to read and write xml documents to/from Java objects in memory. These can then in turn be used to integrate with enterprise systems in Java, or incorporated into Java web components.

RDB code generation

The RDB code generation must be carried out after the Java code generation has been completed. This is because the generated RDB code consists of Java and SQL modules used to integrate with a database. This integration is achieved using generated JDBC modules, which in turn use the generated Java integration modules.

The steps to build the RDB code generation are as follows:

1. Build the types and object integration objects for the schema document as described above.
2. Generate the integration code in Java for the types and object editor templates produced.
3. Compile the Java jar archives, and Java integration modules (also to a jar file).
4. Generate the RDB code for the types and object editor templates.
5. Compile the RDB Java (JDBC) modules into a jar file.
6. Load the generated SQL scripts to the database.

Once these steps have been completed, the generated RDB java modules can be used to integrate with enterprise systems in Java, or used in Java web components.