simple xlsx detail reports:
organization details :
- mint2OrgDetailsubreport.jrxml :
- subreport : mint2derivedtransformationssubreport.jrxml
organization goals details:
- mint2orgDetails3.jrxml :subreports :
project goals overall :
project details overall :
16 + ( 2 common templates) = 18 jrxml files .
Mint2 now supports a data reporting system.
The implementation is based on the Jasper Reports library.
The Report Layout is described by a Java object in our case already compiled into a .jasper file that resides into to the Mint instance runtime path.
These .jasper file have been compiled into binary from an XML file describing the report layout. Designing .jrxml (Jasper Reports XML) report files and compiling into the .jasper objects can be done with the use of an almost WYSIWYG editor like iReport .
Jasper Reports library uses multiple sources as its input. Our implementation uses custom Java beans as an input.
iReport can read the fields of the report input Java Beans through a .jar exported from Eclipse and placed inside iReport’s path.
The .jrxml files although not used at runtime ,in our reports are placed inside the project directory /report_templates. Editing can be made with iReport and the resulting compiled .jasper should be put in the WEB-INF/src/java/gr/ntua/ivml/mint/report.
Retrieval of the data is made through the UrlApi of Mint2 .This allows the reporting system to be ported and run independently by an application, such as a central reporting system, monitoring multiple Mint2 project instances.
At runtime Java beans are constructed after parsing the UrlApi JSON responses corresponding to our requests.
After the JSON is parsed custom Java beans are created and added into Java Collections by classes called factories.
The Collections (Lists) are input into the Jasper Report manager (net.sf.jasperreports.engine.JasperFillManager ) along with the specific .jasper file and some optional parameters .
Output can be in various formats with the use of various libraries. For .xlsx or .csv types the report has to be designed in a minimal way without using much graphics or vertical spaces.
Our report system is implemented into the DownloadReport action. And all the classes describing the Java Beans and the factories are placed into the : WEB-INF/src/java/gr/ntua/ivml/mint/report/
Preview configuration properties support hidden views. They will be used to generate subsequent views, but they will not appear in the UI.
To hide a view add the
In this example, Europeana will be generated based on ESE, but ESE will be hidden.
I created a new action called
Single to facilitate opening single kaiten panels by accessing a URL. In order to use it, you have to specify the action, the action parameters and an optional
kTitle. For example, to directly open mapping tool with specified parameters, you can access
This will redirect to:
which is essentially the same. The added value is that you can type the url without worrying about escaped characters in the url.
I just commited the first implementation of the Mint2 annotator. In order to run it, you have to put this in your
ui.hide.annotator = false
You can then select any dataset in your workspace and select the Annotate option. Alternatively, you could visit the generic Mint2 instance we have on oreo.
The annotator is based on the editor setup of the mapping tool and uses a similar structure for representing the object in memory. It doesn’t save the changes in the database yet, items are only stored in memory for now. Items loaded are not currently linked to a schema, so it is not possible right now to add elements that do not already exist.
So, have a look and we can discuss things in the comments 🙂
The Meta table in Mint2 is a key value store that can hold information not important enough to end up in their own tables.
Basic access to this table is handled by these static methods:
- Meta.put( String key, String value ): Stores a value for the specified key. Replaces the value if the key exists.
- Meta.get( String key ): Gets a value for the specified key or null if the key does not exist.
- Meta.delete( String key ): Deletes entries with the specified key.
The Meta API has also been extended to support storing properties related to database persistent objects. It uses reflection to generate a key based on the object’s class name, the object’s
getDbID method and a property name. The generate key has this form:
Class[dbID].property. The following methods are supported:
- Meta.put( Object object, String property, String value ): Stores a value for the specified object/property pair. Replaces the value if the property exists for this object.
- Meta.get( Object object, String property ): Gets a value for the specified object/property pair or null if the it does not exist.
- Meta.delete( Object object, String property ): Deletes property of the specified object.
- Meta.getAllProperties( Object object ): Gets a list of tuples with all object’s properties and their values.
- Meta.deleteAllProperties( Object object ): Deletes all properties for the specified object. Useful if the object is going to be removed from the database.
An example of using Meta, is storing user preferences for the mapping editor:
User user = ... /* some user object */
Meta.put(user, "mapping.preferences", "some string value that holds user preferences");
The key generated for this object/property pair is
gr.ntua.ivml.mint.persistent.User_$$_javassist_12.mappings.preferences, where 1000 is the dbID.
The preferences are later retrieved by using:
When the user is deleted, the following should also be called:
Mint2 now supports validation using Schematron rules. Schematron rules are related to an XmlSchema instance and can be provided to the system through
appinfo schema annotations, using external schematron files, or both.
Define schematron rules
You can define schematron rules inside an XSD by adding an
appinfo annotation like this (example from ORE.xsd):
<documentation>Aggregated CHO: a link to the original CHO plus a new provider</documentation>
<sch:pattern name="Either Is shownby or is shownat should be present" >
<sch:assert test="edm:isShownAt or edm:isShownBy">A ore:Aggregation must have either edm:isShownAt or edm:isShownBy</sch:assert>
Alternatively, you can provide schematron rules using external schematron files. If the
schematron schema configuration property is defined, the system will first try to locate this file in the same directory the XSD file exists. Otherwise it will try to locate a file with the same name as the XSD file with a .sch suffix (i.e. EDM-INTERNAL.xsd.sch). The system will also try to merge rules defined from xsd and external files.
Schematron validation is available by using the
gr.ntua.ivml.mint.xsd.SchemaValidator class. This class provides variants of the
validateSchematron(Source source, XmlSchema schema, ReportErrorHandler handler) method to validate source using an XSL generated by the schematron rules related to the schema XmlSchema. If a handler
ReportErrorHandler is provided, errors will be added in the handler’s schematronErrors
Schematron XSL generation
The schematron XSL used to validate an xml is generated by the
gr.ntua.ivml.mint.schematron.SchematronXSLTProducer class by using the
This requires a string that contains a complete schematron document. Rules from XSD appinfo annotations can be wrapped in a complete schematron document by using the
wrapRules method and using the schema’s namespace declarations (from schema’s configuration) to include in the document:
XmlSchema schema = <an XmlSchema instance>
String schematronRules = schema.getSchematronRules();
SchematronXSLTProducer schematron = SchematronXSLTProducer.getInstance();
String wrapped = schematron.wrapRules(schematronRules, schema.getConfigurationNamespaces());
String xsl = schematron.getXSL(wrapped);
I added the option to use Crosswalks in preview configuration. For example, instead of specifying the lido to ese XSL file in each preview configuration (and having to update it each time it was changed) we can instead provide the target schema name in the preview. Instead of using this preview configuration:
we can use this:
"target": "ESE 3.4",
ChainTransform object that generates the preview tabs will look for a direct crosswalk from the source schema to the specified target. This should use the same crosswalk used during publication, if the publication schema and preview schema names are the same. So we should be consistent on how to name installed schemas in Mint2 installations. I suggest we use the schema name in capital letters followed by the version (without a ‘v’ prefix) i.e. LIDO 1.0, ESE 3.4.
PS 1. If you omit the label parameter the preview tab will use the target schema name as tab title.
PS 2. In order to update our mint2 installations accordingly, I added the option to rename a schema in Administration > Manage XSDs (see here).
Added per Organization Filtering to UrlApi .
Usage example :
for all types :
- Transformation (added)
if organizationId is not present the query targets the project database.
Mint2.languages includes functions to associate language codes with language labels (used in thesaurus browser widget).
I will describe Mint2.documentation in a future post.