Importing Forms

Aria allows XML documents and forms to be imported and rendered as pages or forms within an application. The imported document can make use of all of Aria and Aria's facilities.

The form import relies on a mapping of types or XML elements and once this mapping has been setup the application can import just about any document that uses the types described in the mapping.

Page Builders

Aria employs an extensible method of loading pages. The page manager normally loads pages from XML or from Java classes if it cannot find a suitable XML page. This process can be altered by setting up secondary page loaders. The page loader is described by the PageLoader interface and can be configured through the startup property value for BuilderClass and NumBuilderClasses. Aria includes several page loaders including Aria's default page loader, an HTML page loader (see Importing HTML.) and a generic page loader for loading forms and other file formats (see Importing forms.).

Using this builder mechanism Aria can handle a wide variety of file formats through the addition of additional builder classes.

The Generic Builder

Aria also includes a menchanism for generically handling different XML file formats. The GenericBuilder is driven with an XML configuration file that describes how various elements in the XML are to be treated. Multiple builders can be installed for different file types and the builders are tested in the order in which they are registered to see if they can load a particular file. The file extension may be used to determine the file type, but this is not always necessary.

The generic builder takes an XML configuration file GenericBuilderConfig named in the startup properties file. Check the builder's documentation for more details as the individual builders may customize this behavior.

Generic Builder Configuration

The GenericBuilder 's configuration file is divided into several sections: components , instructions and attributes .

Component Mapping

The components section defines how XML elements in the source or incoming file format may be transformed to Aria components. The mapping can be one to many, many to one or many to many, so there can be extensive rearrangement and restructuring of the information. The mapping specifies the types of components to be instantiated and the way the attributes are then applied to the new component. For example in the following mapping

Mapping a set element to two Aria components

     <Composite id="Set">
       <Component type="Label" name="caption"/>
       <Component type="List" name="input"/>
       <Attributes>
         <Attribute srcAttrib="name" destAttrib="name" component="input"/> 
         <Attribute srcAttrib="title" destAttrib="content" component="caption"/> 
         <Attribute destAttrib="alignment" value="right" component="caption"/> 
       </Attributes>
     </Composite>

the Set element is rendered as a XLabel and a XList component. Each of the new components is named in the mapping so that the attributes of the Set element can be applied to the two new components depending upon which of the named components is referenced in the Attribute element of the mapping.

Some formats may map an element type to a range of types on the basis of some secondary attributes. The mapping file can specify these attributes with the matchAttrib and matchValue attributes, where the element is matched on the basis of the attribute (or comma separated list of attributes). The component mapping then checks that the source file specifies values for these attributes that match the values specified in the mapping's matchValue attribute (again this can be a comma separated list). When multiple mappings are specified in this way the mappings are searched in the order in which they are specified and therefore it is important to list the mappings so that the most specific mappings are listed first. The last mapping should then be the most generic or default mapping.

When multiple mappings are specified the default mapping may also be specified by including a match value of ` * '.

Attribute Mapping

A file format may use a common attribute across multiple components and rather than having to specify this attributed repeatedly for each component type a common attribute mapping can be specified. For example the following specification:

A common attribute specification

 <Attributes>
   <Attribute srcAttrib="style" 
	destAttrib="${this.setStyle(${comp},${value})}" 
	component="caption"/> 
 </Attributes>

of a style attribute. In the above example the setStyle method is invoked with the component named by the component attribute and the value of the attribute specified in the original element.

If the destAtrrib is missing it is assumed to be the same as the srcAttrib , equally the component name is assumed to be main if unspecified.

Only attributes that are specified are passsed to the component and therefore it is at leaset necessary to name the attributes that are used.

XMultiAttributedComponent interface extends XAttributedComponent and adds the methods endMapping which is called when all the attributes have been set. The purpose of the interface is to allow a component to process the attributes when all are available. The use of allAttributesSet requires that the component stores the attributes (they are stored by the page anyhow, and can be retrieved with the getAttribute method). Compound attributes such as the styles can be set in the way even if the style values are specified separately.

Mapping Instructions

The source XML may contain elements that do not map to components and these elements can be handled by processing instructions.

Extra processing instructions

   <Instructions>
     <Processor id="AlertProcessor" 
		class="org.formaria.oracle.forms.pi.AlertProcessor"/>
     <Instruction id="Spacer">
       <Action method="${addSpacer()}"/>
     </Instruction>
     <Instruction id="RowSpacer">
       <Action method="${addRowSpacer()}"/>
     </Instruction>
   </Instructions>

In the above example the processing instructions specify calls to the addSpacer or addRowSpacer method when Spacer or RowSpacer element are encountered. The builder class may provide some useful methods or the evaluated attribute can reference library methods. In addition to the normal set of library method references the instruction processing may specify an additional instruction processors (each of which implement the XInstructionProcessor interface).

Layering in the rendered form

Since content generated on the fly may exhibit some aspects of a lowest common denominator approach the generic builder allows composition of content through layering. Each layer can be specified separately and tis process makes it possible be combined predefined content (normally in background layers) and dynamically generated content. The predefined content may contain artwork and branding related content such as logos, or the layers may contain common elements such as navigation items and so forth.

Opening HTML within the IDE

A limited form of HTML may be edited within the Aria editor. For this to work the first element in the html must be XHtmlPage .