How to generate data bindings for EDNA

From EdnaWiki
Jump to: navigation, search

The data binding generation in EDNA is basically a way to transform an XSD file into a python class which contains all setters and getters for all attributes in the data-model.

This is done by running the ${EDNA_HOME}/whatever/datamodel/generateXSDataPluginWhatever.sh shell script in order to convert ${EDNA_HOME}/whatever/datamodel/XSDataPluginWhatever.xsd into its pythonic equivalent ${EDNA_HOME}/whatever/src/XSDataPluginWhatever.py

The advantage of doing like this is that you just have to re-run the shell script after having changed the data-model. The data binding will be re-generated and you should never edit the XSDataFile.py by hand.

Don't worry if you not have this shell script now, its creation is part of the PluginGenerator, so if you intent to use the PluginGenerator, you can skip the rest of the document.


In EDNA, we currently use GenerateDS.py (by Dave Kuhlman (2003)) to do the metaprogramming of the data-binding, but we hardly ever call the program directly. Instead, we associate a small shell script called generateXSDataPluginWhatever.sh in the same directory as the XSD file XSDataPluginWhatever.xsd (and also the .png, the .eap, the .xmi). The structure of this file is extremely simple: collect 4 arguments and call the generate binding in a good way.

#!/bin/sh
#full_path="$(cd "${0%/*}" 2>/dev/null; echo "$PWD"/"${0##*/}")"
full_path=$( readlink -fn $0)
export EDNA_HOME=`dirname "$full_path" | sed 's/\/whatever\/datamodel$//'`
xsDataBaseName=XSDataPluginWhatever
xsdHomeDir=${EDNA_HOME}/whatever/datamodel
pyHomeDir=${EDNA_HOME}/whatever/src
includeXSDFilePath=${EDNA_HOME}/kernel/datamodel/XSDataCommon.xsd
sh ${EDNA_HOME}/kernel/datamodel/generateDataBinding.sh ${xsDataBaseName} ${xsdHomeDir} ${pyHomeDir} ${includeXSDFilePath} 

The first block contains the header of a shell script under unix and sets the full_path and the EDNA_HOME variable. If you system does not provide a complete readlink executable, it is possible to use the (cryptic) alternative which is commented out.

The second block defines the four variable like the position of the data binding and (future) location of the sources.

The last block is just a call for the program in the kernel that will convert ${EDNA_HOME}/whatever/datamodel/XSDataPluginWhatever.xsd into its pythonic equivalent ${EDNA_HOME}/whatever/src/XSDataPluginWhatever.py

That's all folks !!


Generate Data Bindings with EDGenerateDS.jar

As an alternative to the formerly Python based data bindings generator there was a new generator developed which uses Xpand as template engine and generates more tailored data bindings classes for EDNA. This generator is exported as an executable JAR, which provided a command-line interface.

Type `java -jar EDGenerateDS.jar` for getting usage information:

java -jar EDGenerateDS.jar 
usage: java org.edna.datamodel.generateds.EDGenerateDS [OPTIONS]
 -includepaths <dir,dir...>   Comma separated list of paths to search for
                              referenced models
 -source <source>             Datamodel source file (.edml or .xsd)
 -targetdir <targetdir>       Target directory

The only required argument is -source, which specifies the path to an input file ending with .edml or .xsd.

java -jar EDGenerateDS.jar -source $EDNA_HOME/edna/kernel/datamodel/XSDataCommon.xsd

The option targetdir specifies the output directory for the resulting .py file. If not specified the program searches first for a src directory on the same level as the datamodel directory containing the source file. If that is not found it searches for a plugins directory. If that is also not found the target directory equals the source directory as fallback.

With includepaths a comma-seperated list of paths that contain dependent datamodel files is specified.

Back to documentation page