This features is available in FlexDoc/XML.
Such data sources (called Data Source Models (or DSMs) and drivers to them – DSM Drivers) can be processed in the same way as XML-files and allow to generate by them any kind of documentation.
See FlexDoc/Javadoc and FlexDoc/Together as rich examples of working with such application-provided data sources.
The involved data sources can be of any possible nature, both XML and non-XML types.
This is achieved by creating special frameset templates. Each frameset template consists of two major parts: the definition of a frameset structure and the template body. The frameset structure is defined in the form of a tree as shown on the following screenshot:
The images can be either taken from the existing graphics files (via URLs, file pathnames or Java resource names specified in the templates) – static images, or generated dynamically by a Java application and, then, provided to the FlexDoc Generator by a custom written DSM Driver (see FlexDoc API for more details).
The supported graphics formats include JPEG, GIF, PNG, and WMF. Depending on the selected output format and the generator's settings, the images can be either inserted as the references to the graphics files stored externally near the generated documents (HTML, RTF) or embedded directly in the document files (RTF). See Image Formatting for more details.
For more information about image support, see also Image Control in Template Components documentation.
The internal links are generated using the special hyperlink source- and target-anchors defined within the properties of template components. Each anchor definition contains specifications for generating the anchor keys.
The following screenshot shows defining two hyperlink source anchors by a Data Control component (the two are because this control generates a text hyperlink which loads two frame windows at once; see description below):
And here is how the particular source anchor defined: The following two screenshot show defining a hyperlink target anchor (there may be also several of them; but in that case, this is only for convenience purpose):
It is also possibility to define by the same template component several hyperlink sources assigned with different document destinations and targeted to different frame windows (see screenshot above). This allows to load from a generated hyperlink several frame windows at once with the different documents.
The following screenshot shows how various hyperlinks are defined for a complex diagram image (specified in the diagram.tpl template included in FlexDoc/XML | XSDDoc):
stringnumberbooleanobject
The 'object' data type represents a reference to any Java object and is useful
when the data source is provided by a Java applications
and represents its internal data.
In addition, FlexDoc recognizes attributes with element identifier data types:
IDIDREFID attributes are used to distinguish particular elements.
The IDREF attributes can be used to obtain the referenced elements
as well as for generation of hyperlinks.
Besides this, all values can be arrays of the above types.
The current FlexQuery implementation supports the following features:
| Arithmetical | +, -, *, /, % |
| String concatenation | + |
| Number comparison | ==, !=, <, <=, >, >= |
| String and other types comparison | ==, != |
| Logical | !, &&, || |
| Conditional | ?: |
| Function call | func (args) |
| Property access | -> or . |
string, number and boolean types
(which are equivalent of Java java.lang.String, java.lang.Number and
java.lang.Boolean classes) can be processed by expression operators.
Values of other types can be only passed as function parameters.
For instance, FlexDoc/Together provides more than 20 additional utility functions which allow to use the functionality specific for Together OpenAPI interfaces.
Step1 / Step2 / ... / StepN
axis :: ETs [filter]
axis is the step's axis;
ETs is a list of matching element types (delimited with '|');
filter is a boolean FlexQuery-expression
StepN, in addition, may assume the form:
@name
name is the name of an attribute.
However, there are several important differences between Location Paths used in FlexDoc and those used in XPath:
childselfchild-or-selfdescendantdescendant-or-selfattribute (only in the form: @name)link was introduced, which has a form:
name^
where name is the name of an attribute whose type should be either IDREF
or IDREF[] (an arrays of IDREF). This axis selects all those elements of the XML document
(or DSM) whose identifiers are listed
in the attribute's value.
filter, which can be any boolean
FlexQuery-expression.
For more information see documentation: Element Iterator | Location Paths.
In addition to elements, it is possible to iterate by a set of attributes of a certain element or by multiple values of a certain attribute. Organizing iterations by sets of attributes can be useful when the same processing should be repeated for each attribute from the set. See Attribute Iterator documentation for more details.
Each Location Rule has the following form:
Matching Element Types → Location Path
Matching Element Types.
Then, the Location Path is interpreted against the
context element and a set of new elements is produced.
IDREF or IDREFS types).
This is achieved by using link-axes (introduced in FlexDoc)
together with specifying some Location Rules as recursive (i.e. repeatable an undefined number of times).
For more details, see documentation:
Element Iterator | Recursive Location Rules.
The following screenshot shows specifying the collecting elements by Location Rules in an Element Iterator:
For more information, see documentation: Element Iterator | Specifying Element Iteration Scope.
Defining sorting by a compound key:
For more information, see documentation: Element Iterator | Sorting and Template Components | Attribute Iterator.