The ReportsAnywhere Schema File
Contents
Sample for view
extensions
Configuring a class view
(scope)
The ReportsAnywhere Schema File |
Contents |
| Sample for view
extensions |
|
| Configuring a class view
(scope) |
ReportsAnywhere uses Java's reflection to analyze the classes for reporting. It uses the schema file for directions which classes must be analyzed.
The minimal information the XML configuration file must specify are the entry points into your data. From these entry points ReportsAnywhere deducts attributes and methods that can appear in a report.
However the number of classes and attributes found may be very large. To many users this is confusing, because there are many more classes/attributes than needed. To reduce the set of classes/attributes the schema generation process can be controlled by the XML configuration file. In this case the configuration file can specify views for the classes, which hide or rename members. Because the physical class can be hidden completely this layer is called the curtain definition.
This is a minimal schema definition file:
<?xml version = '1.0'?> <com.qintsoft.joria.datasources.curtainschema name="TestSamples" dataAccessTrigger="com.qintsoft.joria.examples.curtainschema.SampleDataGenerator" listVisibleJavaClasses="false"> <root name="Products" view="java.util.List" eltype="com.qintsoft.joria.examples.beansapi.Product"/> </com.qintsoft.joria.datasources.curtainschema>
The first two lines specify it as an xml file that contains a curtain definition. The top level element is com.qintsoft.joria.datasources.curtainschema
It specifies a number of
configuration parameters, which are explained in the reference section. It contains at least one or more
root elements which declare the entry points into your data.
There are a some basics required when you want to write a schema file:
Top level element of a curtain defnition. It contains the root declaration and view definition elements.
Attributes:
Order and all its referenced classes
implicitly. Note that listing the classes does not prevent the classes from being used.
They will only be listed, so that you can correct them.
Contained Elements:
Attributes:
You can add any option from Versant to configure your database connection. These will be passed to Versant when the database is opened.
Contained Elements:
Attributes:
Contained Elements:none.
Attributes:
Contained Elements:none.
Attributes:
Contained Elements:none.
Attributes:
Contained Elements:none.
Contains a list of classpath extensions. Each element is wrapped in a <entry> tag.
This defines a data entry point. The name of the root will appear in the data tab of ReportsAnywhere were it can be used to design report templates. The view specifies the data fields you can use in your report template.
Attributes:
Attributes for XML with Jaxb
Attributes for Versant/Java (JVI)
Attributes for Objectivity/Java
A root in objy is specified using a combination of attributes, namely:
The following combinations are possible:
Attributes for Caché with Java projections (not Jalapeno)
Contained Elements: none
A view defines a data type that can be used in reports. Views can be defined for either classes or collections.
A view is a class view if it contains member elements. A
view is a collection view if it has a eltype attribute.
A class view defines which members of a class shall be visible to the report developer. A view is based on a java
class from where it takes its members or on another view. It contains a number of
member elements, which are described below.
Attributes:
Contained Elements:
A collection view controls access to a collection type. Its main purpose is to provide a name that is easy to understand and to declare the element type of the collection. For ReportsAnywhere collections are a very general and important concept. Collections allow you to create tables of object data. The term collection is used for anything that can supply a number of elements of a common type. (Relational tables are mapped to collection in ReportsAnywhere) First and foremost these are the collection classes from the package java.util. However ReportsAnywhere also allows you to create tables from arrays and iterators (java.util.Iterator and java.util.Enumeration) Consequently in ReportsAnywhere arrays or iterators are also simply called collections. In addition ReportsAnywhere provides direct support for the collection classes defined by the Object Data Management Group (package org.odmg).
Java collections except arrays do not have a specific element type. They are just defined as containing objects of type java.lang.Object. However ReportsAnywhere needs the element type to display the fields that become the columns of a table in the report. Therefore the true element type must be specified in the collection view element. This type is used to determine which fields are available as columns in a table, and it is also used to filter the collection according to this type. This means, that a collection view which is declared as containing Persons may contain elements which are not Persons, but the elements which are not Persons will be skipped.
Attributes:
Contained Elements: none
Specifies a data field that appears in the view. A view member comes from a member of the source class or from a
navigation path. One of its purposes is to provide an alias name that is easy to
understand. A member element must contain at least one srcfield or
srcmethod element. If it contains several srcfield or srcmethod elements then this does
specify a navigation path. A navigation path is the equivalent of a java navigation expression hat uses the dot
notation. If during runtime one of the steps in a navigation path evaluates to null,
then the whole path evaluates to null.
Attributes:
Selects a field from the source class that supplies the data for the member. If a method of the same name exists the field is used. To use the method write the name with "()"
Attributes:
Selects a method from the source class that supplies the data for the member. If a field of the same name exists the field is used. To use the method write the name with "()"
Attributes:
Selects a method from the extension class that supplies the data for the member. The name of the extension class
must appear as the extclass attribute in the class view element. The
extclass must be a public static method in the extclass that takes exactly one parameter of the viewed class.
A
sample of extclass
usage.
Attributes:
The data access trigger class is defined by an interface in the package com.qintsoft.joria.runtimeapi.
It is used at runtime to access the data. You only have to implement a function
that returns the value for the roots declared in the curtain definition file. All other data is accessed from this
root using java reflection. As a consequence all data that is required for the
report must be accessible via reflection. (This means it mus be either loaded in advance, or you must use a mechnism
like JDO that dynamically loads data from the database.) If your data is in
memory anyway or if you use an object database like Poet, Versant, Objectivity or ObjectStore then this is trivial.
The data access trigger interface also contains methods which are triggered when a
transaction must be started and when a report is closed. For your convenience there is the class com.qintsoft.joria.runtimeapi.AbstractDataAccessTrigger
which implements most methods.
Details of the classes and interfaces can be found in the
java
documentation for the classes.
| Configuring a class view
(scope) |
Contents |
Sample for view
extensions |