Skipper - The ORM Designer Blog
  • Skipper - The ORM Designer
  • VsBuilds - Parallel building
  • Pulpo - Free Skipper CLI

Tag: #extensions

Skipper beta with Gedmo support available

After some weeks of hard work we are happy to announce that Skipper now supports also Gedmo extensions. New version with the support is so far available as beta, you can download it from a post about Gedmo extensions on our support forum.

Because Gedmo extensions support needed a lot of changes in the application, we are now looking for beta testers who will try it. So if you have a project with Gedmo extensions you are very welcomed to import them in your Skipper model and let us know, whether everything works as expected. We will be really glad for your help :-)

Gedmo extensions support is now available only for Doctrine 2 framework. But this is only temporary, as soon as the beta will be properly tested, also a support for MongoDB ODM will be added.

Execute another application from ORM Designer import/export script

In this short article I want to show you how to execute another application from ORM Designer script. Since the version 1.4.2 ORM Designer has built-in a new script command called “execute-file” serving to launch the foreign applications from script. (1.4.2 is now obsolete, please download latest version from //

Execute-file command

As first, let me show you the simplest way how to use this command.

  <function name='Test'>
    <execute-file file='p:\ExternalUnitTestFiles\DataFormats\Bat\test.bat' params='unit-test'/>

Using this snippet we defined a function called “Test” which launch our testing .bat file with parameter ‘unit-test’. Whole command syntax is defined in XML Schema file script.xsd and looks like this:

<xs:complexType name="sExecuteFile">
  <xs:attribute name="file" use="required" type="xs:string"/>
  <xs:attribute name="params" type="xs:string"/>
  <xs:attribute name="show" type="booleanEx" default="true"/>
  <xs:attribute name="working-dir" type="xs:string"/>
  <xs:attribute name="wait-for-exit" type="booleanEx" default="true"/>

By using parameter “working-dir we can specify a working directory for executed command. If no param is passed,  the directory where executable file is located is used. Parameter “show serves to launch application in invisible mode and parameter “wait-for-exit” servers to wait until external application has finished its work and then continues with script.

Overloading export script

Now let me show you another new feature of ORM Designer 1.4.2. It can happen that you need to call your own executable when ORM Designer finishes export from model to ORM framework definition files. So we prepared new overloading points in export script, where you can write your own functions which will be called in this points.

Overloading basis

Method overloading in ORM Designer script is processed by method names and prefixes. The simplest way is by defining a function with specific name. ORM Designer runs this function when it is available.

Sometimes we need to distinguish functions for concrete type of ORM. In this case ORM Designer offers prefix overloading ability. ORM Designer tries to find several prefixes when searching for specific function.

These prefixes have fixed order and priority, so we can define a  specific version of some ORMs and one common function for the rest of ORMs.

Order and prefixes are defined in following list. At first ORM Designer tries to find the function with “MVC.ORM.” prefix. As next ORM Designer tries “ORM.” prefix, then “default.” and then without prefix.

ORM Designer stops the function search after a function with correspond name has been found .


So, when you have following definitions, if project using Doctrine ORM is being processed, the first function will be called. When processed project uses any other ORM, the second function is called:

<function name='Doctrine.Test'/>
<function name='Test'/>

Overloading in export script

Every export script has in its end a located fragment which enables us to call our overloaded function. This fragment looks like:

<call name='system.NotifyEvent'>
  <param name='projectID' value='${projectID}'/>
  <param name='functioName' value='onFinish.export'/>

Now, if you need to create a custom function which is called anytime when ORM Designer exports model to ORM Definitions, follow next steps. As first, we create a file onfinish-export.uscript.xml (or any other name with “.uscript.xml” extension) in user configuration directory (more about user configuration files). As next, enter following script snippet to the created file:

<?xml version="1.0" encoding="utf-8" standalone="no" ?>
  <!-- ==== Doctrine2.onFinish.Export ==== -->
  <function name='Doctrine.onFinish.export'>
    <execute-file file='test.bat' params='Doctrine'/>
  <!-- ==== default.onFinish.Export ==== -->
  <function name='default.onFinish.export'>
    <execute-file file='test.bat' params='default'/>

Now, every time when ORM Designer exports a model it will execute one of these functions, based on the project ORM type.


Currently, a support for user-callbacks in scripts is limited only to export scripts. In future, we would like to add more callbacks places depending on users’ requirements. If you have any questions about this topic, feel free to contact us.

12 Oct 2010

Posted by: Ludek Vodicka

Extending Skipper #import-export #extensions

Create support for your own framework in ORM Designer, part VII – export script

Part VII: How to write an export script

In this part of our serie I want to show you how to create an export script for your ORM framework. I’m going to show you basic script commands and how to communicate with ORM Designer project from the script. For an advanced usage of script language it is recommended to study the original ORM Designer scripts for Doctrine, Doctrine2, Propel and other frameworks located in Scripts folder in ORM Designer installation folder. Basic syntax of ORM Designer script is based on Phing XML language.

Export script testing

Before we start to write our first export script, I’m going to show you how to test and debug your scripts.  Article with all informations about this topic is available here Currently we need following switches:

OrmDesignerCore.exe -unit-test-import-export -input-project c:\project.ormdes -output-orm-file c:\project.out.xml
OrmDesignerCore.exe -unit-test-import-export -input-project c:\project.ormdes -output-export

First statement runs ORM Designer and load project stored in file “c:\project.ormdes”. After the project has been loaded, the whole project is exported into a single file “c:\project.out.xml”.

Second statement also runs ORM Designer and load stored project. After that, project is exported in the same way as after user’s click on “Export” button in ORM Designer application.

Note: Project stored in “project.ormdes” mu</span>st have “AtomixORM” as ORM type.

Minimal script

Now let’s see our minimal export script and how it will be launched by the command from previous paragraph:

<function name='AtomixORM.export'>
    <is-set variable='projectID'/>
    <default variable='exportToOneFile' value=''/>

Script “AtomixORM.export” will be executed with following values:

  • projectID: This variable will contain internal ID of project to export.
  • exportToOneFile: This variable will contain “c:\project.out.xml” in first command-line case, and is empty in second case.

First simple script

Now let’s add few commands to our export script. As first step we tell ORM Designer to export the selected project to a single temporary XML file and then copy this file to the output file determined by command line param:

<function name='AtomixORM.export'>
    <is-set variable='projectID'/>
    <default variable='exportToOneFile' value=''/>
    <not-equal value1='${exportToOneFile}' value2=''/>
      <get-tmp-file-name variable='tmpOneFileExport' dir='ormd-export'/>
      <ormd-export-file output-xml='${tmpOneFileExport}' project='${projectID}'/>
      <copy-file from='${tmpOneFileExport}' to='${exportToOneFile}'/>
  • By using “if” and “not-equal” we test if variable “exportToOneFile” isn’t empty. If it is true, we execute export statements which saves the whole project to one file.

  • “get-tmp-file-name” command assigns a unique temporary file name to variable tmpOneFileExport. Attribute “dir” serves to setup usage of subdirectory in temp directory. Result temporary file in our case will look like “….\temp\ormd-export\tmpXXXXXX.tmp”.
  • By using a next command “ormd-export-file” ORM Designer exports project with a certain ID into output XML file determined by output XML attribute.
  • The last command will copy file from the temporary location to a destination path determined by exportToOneFile variable.

This script isn’t much useful yet, but helps us to demonstrate how ORM Designer proceeds data export and allows you to examine how XML file exported from ORM Designer looks like. With this file we will do the next transformations and operations in next parts of this tutorial.

XSLT transformation

The next important step in import and export scripts are  the XSLT transformations. Now I’m going to show you how to transform an exported ORM Designer XML file to another XML file required by your ORM framework. Let’s replace our previous script by following new one:

<function name='AtomixORM.export'>
    <is-set variable='projectID'/>
    <default variable='exportToOneFile' value=''/>
    <not-equal value1='${exportToOneFile}' value2=''/>
      <get-tmp-file-name variable='tmpOneFileExport' dir='ormd-export'/>
      <ormd-export-file output-xml='${tmpOneFileExport}' project='${projectID}'/>
      <xsl-transformation xslt='AtomixOrm/Xml2AtomixOrmAbstractXml.xslt' input-xml='${tmpOneFileExport}' output-xml='${tmpOneFileExport}_2'/>
      <copy-file from='${tmpOneFileExport}_2' to='${exportToOneFile}'/>
      <delete-file file='${tmpOneFileExport},${tmpOneFileExport}_2'/>

By using the command “xsl-transformation” we will perform XSLT transformation by using XSL template passed by “xsl” attribute (path is relative to script location). Other two attributes determine input and output XML file. Next new command which I use in this example is “delete-file”. After we procees all required steps, it’s a good practice to clean up all temporary files. So we delete both of them.


If you want to store results from your script for debug purposes to some folder, you can use following statement:

<!-- debug -->
<copy-file from='${tmpOneFileExport}' to='c:\ORM\US\AtomixOrm.export-1-proj-onefile.xml' only-debug='true'/>

This statement will be executed only if script runs only on debug  mode (export launched by using command line statement -unit-test-import-export).


Now let’s look to a simple XSL template used for transformation:

<xsl:stylesheet version="1.0" xmlns:xsl="" xmlns:saxon="">
  <xsl:output indent="yes"/>
	<xsl:template match="*">
      <xsl:apply-templates select="/orm-designer/module"/>
	<xsl:template match="/orm-designer/module">
    <import-export-file import-path="{@import-path}" import-format="{@import-format}">
        <xsl:copy-of select="./*"/>

This template creates XML with root element “import-export-document” which contains several “import-export-file” elements. These elements will contain copy of exported model from ORM Designer. We will use this prepared XML later in this tutorial to split file to several output XML files.

Example project files

Here is all files used in this tutorial:

Debug output

When you run ORM Designer with a command line params from the beginning of this article, you should see output like this:

(0019)Running function [AtomixORM.export] from file [p:/OrmDesignerCore/SetupCreator/Installed/config/AtomixOrm/AtomixOrm.uscript.xml]
(0020)  check
(0021)  - exist-variable [projectID]=TRUE (11)
(0022)  - default-variable-value [exportToOneFile] Exists=TRUE
(0020)  result-check = [TRUE]
(0026)  if
(0027)  - equal ['c:\project.out.xml'!='']=>TRUE
(0026)  - RESULT = [TRUE]
(0029)    get-tmp-file-name[tmpOneFileExport,ormd-export]=C:\Users\...\Temp\ormd-export\tmp7E69.tmp
(0030)    ormd-export-file [P:11] C:\Users\...\Temp\ormd-export\tmp7E69.tmp,
(0033)    copy-file[C:\Users\...\Temp\ormd-export\tmp7E69.tmp,c:\ORM\US\AtomixOrm.export-1-proj-onefile.xml]
(0036)    xsl-transform[p:\OrmDesignerCore\SetupCreator\Installed\config\AtomixOrm\Xml2AtomixOrmAbstractXml.xsl,C:\Users\...\Temp\ormd-export\tmp7E69.tmp,C:\Users\...\Temp\ormd-export\tmp7E69.tmp_2]
(0037)    copy-file[C:\Users\...\Temp\ormd-export\tmp7E69.tmp_2,c:\project.out.xml]
(0040)    delete-file[C:\Users\...\Temp\ormd-export\tmp7E69.tmp,C:\Users\...\Temp\ormd-export\tmp7E69.tmp_2]
(0040)    - deleting C:\Users\...\Temp\ormd-export\tmp7E69.tmp
(0040)    - deleting C:\Users\...\Temp\ormd-export\tmp7E69.tmp_2
Press any key to close the log.

Advanced export script

In previous paragraphs I showed you few simple examples of export script. Now let’s look at more complicated export which exports data to several xml files. In this example I want to show you next new commands and scripting technique. First I’m going to show you a full script listing and then explain every single step.

<function name='AtomixORM.export'>
    <is-set variable='projectID'/>
    <default variable='exportToOneFile' value=''/>
  <!-- (1) export data from ORM Designer -->
  <get-tmp-file-name variable='tmpOneFileExport' dir='ormd-export'/>
  <ormd-export-file output-xml='${tmpOneFileExport}' project='${projectID}'/>
  <!-- (2) debug -->
  <copy-file from='${tmpOneFileExport}' to='c:\ORM\US\AtomixOrm.export-1-proj-onefile.xml' only-debug='true'/>
  <!-- (3) xslt transformation -->
  <xsl-transformation xslt='Xml2AtomixOrmAbstractXml.xsl' input-xml='${tmpOneFileExport}' output-xml='${tmpOneFileExport}_2'/>
  <!-- (4) debug -->
  <copy-file from='${tmpOneFileExport}_2' to='c:\ORM\US\AtomixOrm.export-2-after-first-transform.xml' only-debug='true'/>
  <!-- (5) split xml file to separated files -->
  <get-tmp-path variable='tmpSplitOutput' dir='ormd-export'/>
  <xml-split-file input-xml='${tmpOneFileExport}_2' output-xml-path='${tmpSplitOutput}' variable='splitFiles' />
  <!-- (6) do export for each file -->
  <for-each list='${splitFiles}' variable='file'>
    <!-- (7) debug -->
    <copy-file from='${file}' to='c:\ORM\US\AtomixOrm.export-3-splited-file.xml' only-debug='true'/>
    <!-- (8) read destination file from file -->
    <xml-read-values input-xml='${file}'>
      <read-value xpath='/import-export-file/@import-path' variable='destination_path'/>
    <!-- (9) if there is no destination-path for this module, skip it-->
      <equal value1='${destination_path}' value2=''/>
    <!-- (10) do transform for output file -->
    <xsl-transformation xslt='AtomixOrmAbstract2AtomixOrmXml.xsl' input-xml='${file}' output-xml='${file}_2'/>
    <!-- (11) debug -->
    <copy-file from='${file}_2' to='c:\ORM\US\AtomixOrm.export-4-converted-xml-yml.xml' only-debug='true'/>
    <!-- (12) Save generated result. If exportOneFile is set, all result is stored to this file, otherwise file is stored to export location -->
      <equal value1='${exportToOneFile}' value2=''/>
        <copy-file from='${file}_2' to='${destination_path}'/>
        <append-file from='${file}_2' to='${exportToOneFile}'/>
    <!-- (13) clean-up -->
    <delete-file file='${file},${file}_2'/>
  <!-- (14) clean-up -->
  <delete-file file='${tmpOneFileExport}_2,${tmpOneFileExport}'/>

Here is the explain of each step of this script:

  1. Generate temporary file name and call export from ORM Designer project.
  2. Copy generated file to our debug location.
  3. Call XSLT transformation on exported XML file.
  4. Copy transformed file to our debug location.
  5. Split transformed XML file by root children to separated files. These files will be stored in temp/ormd-export folder. List of the files will be stored in $splitFiles variable.
  6. Now enumerate all splitted files one by one.
  7. Copy splitted file to debug location.
  8. Read value from splitted file by using xpath expression “/import-export-file/@import-path” to variable $destination_path.
  9. If variable @import-path isn’t filled, skip next expressions and proceed next file.
  10. Call next XSLT transformation on splitted file. File is again stored in temp with postfix “_2”.
  11. Copy transformed file to our debug location.
  12. Save exported and transformed result to destination file or append it to passed one-file path.
  13. Delete temporary files from this cycle.
  14. Delete another temporary files from this script.

Pretty simple, right? ;-). There is a lot of things that can be done by ORM Designer scripting language. But this sample should be sufficient to learn you how to create the export scripts for your framework. This script with both XSLT templates could be downloaded here: Final export script example.

Script execution

Now you can run this script in one-file export mode and also in full export mode. When you run this script by using “-output-orm-file c:\project.out.xml” param, file project.out.xml should content this:

<?xml version="1.0"?>
  <table name="Contact" visPositionX="28" visPositionY="36" visSizeX="0" visSizeX2="20" visSizeY="0" visSizeY2="20">
    <column auto-increment="true" name="ID" primary="true" required="true" type="integer"/>
    <column name="Name" type="string"/>
  <table name="Address" visPositionX="17" visPositionY="136" visSizeX="0" visSizeX2="113" visSizeY="0" visSizeY2="73">
    <column auto-increment="true" name="ID" primary="true" required="true" type="integer"/>
    <column name="Street" type="string"/>
    <column name="City" type="string"/>
    <column name="Contact_ID" type="integer"/>
  <foreign-key caption="Contact Address" from="Address" name="FK_Address_Contact_ID" to="Contact">
    <foreign-key-column from="Contact_ID" to="ID"/>
<?xml version="1.0"?>
  <table name="BlogPost" visPositionX="56" visPositionY="100" visSizeX="0" visSizeX2="113" visSizeY="0" visSizeY2="59">
    <column auto-increment="true" name="ID" primary="true" required="true" type="integer"/>
    <column name="Text"/>
    <column name="Contact_ID" type="integer"/>
  <foreign-key caption="Contact BlogPost" from="BlogPost" name="FK_BlogPost_Contact_ID" to="Contact">
    <foreign-key-column from="Contact_ID" to="ID"/>

As you can see, this is not valid XML file. This file is useful in unit-testing stage of your development process. You can simply compare result from export to some required pattern file. If you want to export data in the same format in which your users will see them, use second command line parameter “-output-export”. After that, two files “models\app.xml” and “models\plugin.xml” will be created.

Debug log from processing of this script will look like this:

(0019)Running function [AtomixORM.export] from file [p:/OrmDesignerCore/SetupCreator/Installed/config/AtomixOrm/AtomixOrm.uscript.xml]
(0020)  check
(0021)  - exist-variable [projectID]=TRUE (19)
(0022)  - default-variable-value [exportToOneFile] Exists=TRUE
(0020)  result-check = [TRUE]
(0026)  get-tmp-file-name[tmpOneFileExport,ormd-export]=C:\Users\...\Temp\ormd-export\tmp1DBD.tmp
(0027)  ormd-export-file [P:19] C:\Users\...\Temp\ormd-export\tmp1DBD.tmp,
(0030)  copy-file[...\Temp\ormd-export\tmp1DBD.tmp,c:\ORM\US\AtomixOrm.export-1-proj-onefile.xml]
(0033)  xsl-transform[p:\OrmDesignerCore\SetupCreator\Installed\config\AtomixOrm\Xml2AtomixOrmAbstractXml.xsl,...\Temp\ormd-export\tmp1DBD.tmp,...\Temp\ormd-export\tmp1DBD.tmp_2]
(0036)  copy-file[...\Temp\ormd-export\tmp1DBD.tmp_2,c:\ORM\US\AtomixOrm.export-2-after-first-transform.xml]
(0039)  get-tmp-path[tmpSplitOutput,ormd-export]=...\Temp\ormd-export
(0040)  xml-split-file [...\Temp\ormd-export\tmp1DBD.tmp_2,...\Temp\ormd-export,splitFiles]
(0040)  - splitting file [...\Temp\ormd-export\_tmp100830173657742.tmp]
(0040)  - splitting file [...\Temp\ormd-export\_tmp100830173657753.tmp]
(0043)  for-each[file<='...\Temp\ormd-export\_tmp100830173657742.tmp,...\Temp\ormd-export\_tmp100830173657753.tmp'](0043)  - iteration [file=...\Temp\ormd-export\_tmp100830173657742.tmp]
(0045)    copy-file[...\Temp\ormd-export\_tmp100830173657742.tmp,c:\ORM\US\AtomixOrm.export-3-splited-file.xml]
(0048)    xml-read-values [...\Temp\ormd-export\_tmp100830173657742.tmp]
(0049)    - read-values [/import-export-file/@import-path=>destination_path] value:'c:\Article\models\app.xml'
(0053)    if
(0054)    - equal ['c:\Article\models\app.xml'='']=>FALSE
(0053)    - RESULT = [FALSE]
(0061)    xsl-transform[p:\OrmDesignerCore\SetupCreator\Installed\config\AtomixOrm\AtomixOrmAbstract2AtomixOrmXml.xsl,...\Temp\ormd-export\_tmp100830173657742.tmp,...\Temp\ormd-export\_tmp100830173657742.tmp_2]
(0064)    copy-file[...\Temp\ormd-export\_tmp100830173657742.tmp_2,c:\ORM\US\AtomixOrm.export-4-converted-xml-yml.xml]
(0067)    if
(0068)    - equal ['c:\project.out.xml'='']=>FALSE
(0067)    - RESULT = [FALSE]
(0073)      append-file[...\Temp\ormd-export\_tmp100830173657742.tmp_2,c:\project.out.xml]
(0078)    delete-file[...\Temp\ormd-export\_tmp100830173657742.tmp,...\Temp\ormd-export\_tmp100830173657742.tmp_2]
(0078)    - deleting ...\Temp\ormd-export\_tmp100830173657742.tmp
(0078)    - deleting ...\Temp\ormd-export\_tmp100830173657742.tmp_2
(0043)  - iteration [file=...\Temp\ormd-export\_tmp100830173657753.tmp]
(0045)    copy-file[...\Temp\ormd-export\_tmp100830173657753.tmp,c:\ORM\US\AtomixOrm.export-3-splited-file.xml]
(0048)    xml-read-values [...\Temp\ormd-export\_tmp100830173657753.tmp]
(0049)    - read-values [/import-export-file/@import-path=>destination_path] value:'c:\Article\models\plugin.xml'
(0053)    if
(0054)    - equal ['c:\Article\models\plugin.xml'='']=>FALSE
(0053)    - RESULT = [FALSE]
(0061)    xsl-transform[p:\OrmDesignerCore\SetupCreator\Installed\config\AtomixOrm\AtomixOrmAbstract2AtomixOrmXml.xsl,...\Temp\ormd-export\_tmp100830173657753.tmp,...\Temp\ormd-export\_tmp100830173657753.tmp_2]
(0064)    copy-file[...\Temp\ormd-export\_tmp100830173657753.tmp_2,c:\ORM\US\AtomixOrm.export-4-converted-xml-yml.xml]
(0067)    if
(0068)    - equal ['c:\project.out.xml'='']=>FALSE
(0067)    - RESULT = [FALSE]
(0073)      append-file[...\Temp\ormd-export\_tmp100830173657753.tmp_2,c:\project.out.xml]
(0078)    delete-file[...\Temp\ormd-export\_tmp100830173657753.tmp,...\Temp\ormd-export\_tmp100830173657753.tmp_2]
(0078)    - deleting ...\Temp\ormd-export\_tmp100830173657753.tmp
(0078)    - deleting ...\Temp\ormd-export\_tmp100830173657753.tmp_2
(0082)  delete-file[...\Temp\ormd-export\tmp1DBD.tmp_2,...\Temp\ormd-export\tmp1DBD.tmp]
(0082)  - deleting ...\Temp\ormd-export\tmp1DBD.tmp_2
(0082)  - deleting ...\Temp\ormd-export\tmp1DBD.tmp
Press any key to close the log.

### Conclusion

In this example I showed you how to create the export script for ORM Designer. This topic might be a little complicated to understand, so if you find anything understandable, please leave us a comment bellow the post or contact me on [email protected]. If you are seriously interested in creating of support for your ORM Framework, please let us know. We will prepare the support for you for free if you have large enough community which can be interested in. If you have your own company framework and want to prepare support for your internal ORM, please let us know too, we also offer creating of an ORM support for company customers.

26 Aug 2010

Create support for your own framework in ORM Designer, part VI – import / export

Part VI:  How to define an import/export from ORM Designer model to ORM

Now lets look on next important step for ORM framework support implementation into ORM Designer. It is a data import and export between ORM Designer and ORM framework. Both of these steps are implemented separately and don’t have to solved at all. In some framework for example it isn’t needed or possible to do import. That’s why only a support for data export from ORM Designer into ORM is created. In order to make import/export as flexible as possible, XML script language springing from Phing language syntax is used for script writing.

Firstly lets show how to set in our configuration which scripts should be used for import/export:

<framework-configuration name="AtomixMVC">

During ORM framework configuration is possible to enter 3 different scripts:

  • script-import: script used during model import into ORM Designer
  • script-export: script used during export from ORM Designer to ORM definitions
  • script-import-files-scanner: script serving to automatic finding of all definition files during automatic import

ORM Designer automatically loads all the scripts which are saved in files with mask *.uscript.xml. These files can be stored in anywhere in %ORM_Designer_Path%\Config or in %User_Application_Data%\OrmDesignerCore\config. Concrete location of these files can be found in ORM Designer configuration window at System Info tab:

Script files

Now we are going to show how the file with a simple script looks like. In directory %User_Application_Data%\OrmDesignerCore\Config\AtomixORM we create a file AtomixOrm.uscript.xml. Into this file we enter following XML fragment:

<?xml version="1.0" encoding="utf-8" standalone="no" ?>
  <!-- ========== AtomixMvc.Import.Scanner.AtomixOrm ========== -->
  <function name='AtomixMvc.import.scanner.AtomixOrm'>
      <is-set variable='directory'/>
  <!-- ========== AtomixORM.Import ========== -->
  <function name='AtomixORM.import'>
      <is-set variable='lstFiles'/>
      <is-set variable='projectID'/>
  <!-- ========== AtomixORM.Export ========== -->
  <function name='AtomixORM.export'>
      <is-set variable='projectID'/>
      <default variable='exportToOneFile' value=''/>

By this we have created the scripts which will be executed during the data import or export.

Initial values description

Each script has several initial values which we check by the command <check>. Here is their list.

  • Import script
    • lstFiles:a list of files to import
    • projectID: project ID to which the files should be imported
  • Export scirpt
    • projectID:project ID from which we will export
    • exportToOneFile: This variable determines an output file of project export when  project have to be exported to one file.
  • Import scanner scirpt
    • directory: Determines a directory in which the files for import should be found


In this article we have shown how to configure and create basic scripts for ORM Designer. In next parts of serial we will step by step describe how to implement single scripts together with the explanations of some script language commands. If you have any question about this or following chapter, don’t hesitate and ask us directly here on the blog or you can contact us at [email protected].

26 Aug 2010

How to create support for your own framework in ORM Designer, part V – inheritance support

Part V: how to specify inheritance support

In this part of the serial we are going to show how to configure inheritance types for ORM Designer. Regarding to fact that each framework may support different inheritance types, ORM Designer allows to define inheritance types by the XML configurations.

Again we start with an example from our configuration file AtomixOrm.cfg.xml:

<orm-configuration name="AtomixORM">
	<orm-inheritance-type name="SINGLE_TABLE" caption="Simple inheritance" discriminator-column-type="text" discriminator-column-size="255"/>
	<orm-inheritance-type name="JOINED" caption="Class table inheritance" discriminator-column-type="text" discriminator-column-size="255"/>
	<orm-inheritance-type name="MAPPED_SUPERCLASS" caption="Mapped superclass"/>

If you use the code from this example in ORM Designer you should see following options when marking the inheritance:


  • name Name of inheritance
  • caption Visual caption of inheritance. This value is shown in inheritance-wizard dialogs.
  • discriminator-column-type When discriminator field is automatically created in root inheritance table, this type is assigned to new field.
  • discriminator-column-size Same as discriminator-column-type. Set size of a new created field.

If you have any question about this or following chapter, don’t hesitate and ask us directly here on the blog or you can contact us at [email protected].

26 Aug 2010

How to create support for your own framework in ORM Designer, part IV – default values

Part IV: How to predefine values in ORM Designer

In this part of serial lets show how to pre-set some initial values for our framework.

In the case we use ORM in a combination with MVC framework, a directory structure for data saving is exactly specified. In this case it is possible to set default values in ORM Designer configuration files, which are used during creation of new objects in a model.

Firstly again an example from configuration file:

<framework-configuration name="AtomixMVC">
	<supported-orm name="AtomixORM"
		default-first-module-name="Atomix application"

Now lets go through single params of attribute <supported-orm> together with an example of their usage:

  • default-new-module-file-name and default-new-module-path These attributes serve to set initial value during a creation of a new module. File-name determines a name of file, path determines a relative path to file with a project (*.ormdesigner). The result path is then composed from module-path and module-file-name as shown in following picture.
  • default-first-module-file-name, default-first-module-path and default-first-module-name These attributes serve to set attributes of initial module which is created together with a new project. Module-path and module-file-name determine relative path to project, module-name determine visual caption of newly created module.
  • default-export-module-data-format and default-export-module-path By these setting we can automatically define a format for data export into ORM framework. More about data export in chapter VI - import / export. Each newly created module (including the first module created with new project) has set this export format and export path.
  • script-import-files-scanner This param serves to set a script which is used during automatic data import of our framework. More about this param in chapter VI - import/export.

If you have any question about this or following chapter, don’t hesitate and ask us directly here on the blog or you can contact us at [email protected].

25 Aug 2010

How to create support for your own framework in ORM Designer, part III – custom ORM properties

Part III: How to define custom ORM properties for any object type (entity, field, module, association, …)

This article is a part of serial about implementation of a support for an own ORM into ORM Designer. Now we are going to show how to add definitions of single properties which are specific for our ORM framework. Each ORM framework has several specific properties which uses for its configuration. By these properties you can modify entity behaviours, a way of work with fields etc. Therefore ORM Designer has a complex system for definition of these properties.

Here is an article describing all options of ORM properties configuration. How to configure new ORM properties and data types. Then we recommend to check up other ORM frameworks configurations where you can find many of ORM properties definitions (available in application directory OrmDesignerCore\config). These definitions can serve you as examples of all options of usage.

Now lets show how we can set several attributes for entity and field in our AtomixORM framework.

<orm-configuration name="AtomixORM">
	<attribute name="TABLE">
		<attribute name="useTable" type="string" help="Custom database table name"/>
		<attribute name="cacheQueries" type="bool" help="Whether or not to cache queries for this entity."/>
	<attribute name="COLUMN">
		 <attribute name="readonly"  type="bool" help="Checks if a field is modified."/>

After saving of above mentioned definition into our configuration file (and restarting ORM Designer) we can see following properties in ORM Designer:

Element description <attribute>

In our example we define 2 attributes for the entity and 1 for the field. The attribute definition is proceeded by writing down the element <attribute> with attribute name including one of following enabled values:


Into this root <attribute> then we insert one or more child elements by which we create a hierarchy of the properties. Each element attribute can have following attributes:

  • name An attribute name, this attribute is required.
  • type An attribute data type. Currently the following values are enabled:
    • STRING, DECIMAL, FLOAT, BOOL: Simple values.
    • ENUM, ENUM-RO: Enumeration values. In case of using ENUM-RO isn’t possible to enter other value than pre-defined.
    • COLUMN, TABLE, TABLE-PARENTS, TABLE-CHILDREN. A list of fields, all entities or parent/children entities
    • PATH-RELATIVE, PATH-ABSOLUTE, FILE-RELATIVE, FILE-ABSOLUTE: File data types. Relative paths are relative to project root file (.ormdesigner)
    • STRUCT - Defines a complex data type which holds another property. If has any child, this type is automatically assigned.
    • LIST,SET - A list or set of structs
  • abstract Used in a combination with LIST/SET and STRUCT. If have abstract="true" flag then this attribute isn't displayed in ORM editor and show only children.
  • child-type Used in a combination with LIST/SET to define child types of this attribute.
  • default A default value, currently not implemented.
  • enum-value Defines values which are offered to a user when editing this attribute. Values are separated by .
  • help A help text displayed in the bottom of ORM editor.
  • help-url Url to more information about selected attribute. Currently not implemented.
  • inherit Defines another attribute to inherit all his childs. Usefull when lots of attribute share simmilar child values.
  • export-tag Export-tag is added to element when exporting model to ORM definitions. Usefull to add additional information for XML processing.
  • merge-column Used for internal usage only.

More information about ORM properties defining can be found in the article How to configure new ORM properties and data types.

  • Note: Names of each type spring from historical reasons from ERD diagram. That’s why in place of ENTITY is used TABLE etc.
  • Note2: Some of types can’t be currently visually edited in ORM Designer. These types are INDEX-COLUMN, INHERITANCE-PARENT a FOREIGN-KEY-COLUMN.

If you have any question about this or following chapter, don’t hesitate and ask us directly here on the blog or you can contact us at [email protected].

25 Aug 2010

How to create support for your own framework in ORM Designer, part II – ORM data types

Part II: define ORM data types

In this part of the serial about a support implementation for an own ORM into ORM Designer we are going to show you how to configure ORM framework data types. Each ORM uses its own types that reflect the framework orientation and usage. That’s why ORM Designer offers the possibility of all types setting.

Here you can find an article about preliminary settings and configuration files creating.

An example of several data types settings for our AtomixORM:

<orm-configuration name="AtomixORM">
	<orm-data-type name="integer"   unified-name="@INTEGER,@INT" primary-key-data-type="true"/>
	<orm-data-type name="string"    unified-name="@TEXT,@LONGVARCHAR,@VARCHAR,@CHAR"/>
	<orm-data-type name="date"      unified-name="@DATE"/>
	<orm-data-type name="time"      unified-name="@TIME"/>
	<orm-data-type name="enum"      unified-name="@ENUM" has-enum-values="true"/>

If you have defined ORM data types as shown in our XML example, during an entity editing you should see following data types in field editor:

Element description <orm-data-type>

For the data type defining use an element orm-data-type. Here is a description of all its attributes:

  • name This is the only one attribute which is required. It includes a data type name.
  • unified-name By this attribute it is possible to enumerate the data types that are transformed into a specific ORM data type during an import from external applications or another sources. For example when is a model imported from a database. All the columns with datatype TEXT,LONGVARCHAR,VARCHAR and CHAR will be transformed to ORM data type string. All the datatypes in “unified-name” attribute have to start with char @.
  • primary-key-data-type By this attribute is defined which of datatypes is used as datatype for automatically created primary keys. If more datatypes have this attribute, the first found attribute will be used.
  • has-enum-values By this attribute are marked the datatypes of enumeration type. Currently using of this attribute has no influence on any ORM Designer functionality. We recommend to fill this attribute because it can be used in future ORM Designer versions with new functions implementation.
  • If you have any question about this or following chapter, don’t hesitate and ask us directly here on the blog or you can contact us at [email protected].
25 Aug 2010

How to create support for your own framework in ORM Designer, part I – basic XML configuration


Currently there exists a batch of smaller, rising or corporate ORM frameworks which can also benefit from ORM Designer. In next parts of this serial we are going to show how to easily implement a support for an own framework in ORM Designer.

The whole implementation is very simple and customizable. Configuration consists of settings of several configuration XML files, implementation of XSLT templates for data import and export from ORM Designer format into ORM framework native data and writing scripts that process the single steps and these configuration (the script arises from the syntax of script language Phing).

In these articles we are going to describe how to create a support for imaginary framework AtomixORM. Step by step we are going to show the implementation of required parts for allowing ORM Designer to work with target ORM.

In following page is available several documents concerning ORM Designer file structure, a work with configuration repository etc.

Part I: create basic XML configuration for our framework.

We start with a creation of basic configuration file AtomixOrm.cfg.xml. We place it to a user’s configuration repository (more information you can find in the article Configuration files location and validation), which is in this directory:


We are assuming that besides ORM you have also some MVC framework which this ORM uses. In our case we call the MVC framework as AtomixMVC. Hence, we write into our configuration file the following code:

<?xml version="1.0" encoding="utf-8"?>
  <framework-configuration name="AtomixMVC">
		<supported-orm  name="AtomixORM"/>
  <orm-configuration name="AtomixORM">

By this code we define our AtomixMVC and AtomixORM. Now if you restart ORM Designer you should see the following screen during new project creation.

Note: For more information about the single elements and its all allowed attributes look at XML schema for configuration files - configuration.xsd. This and other schemata for all types of XML files are available in an application directory in subdirectory Schema (i.e.: “c:\Program Files (x86)\OrmDesignerCore\Schema”).

If you have any question about this or following chapter, don’t hesitate and ask us directly here on the blog or you can contact us at [email protected].

25 Aug 2010