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

Tag: #orm designer

ORM Designer presentations

Since a lot of you have asked, we prepared presentations about ORM Designer. Now you can show your teammates or anyone else, who may be interested in ORM Designer, what it can bring. With these slideshows you can demonstrate ORM Designer functionality to your team leader when needed more arguments to his conviction.

Prepared documents are suitable for personal presentation as well as for sending by email as the contained text has highly informative character. If you would like to add or modify something, please write it here to comments.

You can download these documents on the ORM Designer documentation website: or directly on slideshare. Feel free to share it.

ORM Designer presentation

Do you need any other support materials? We will be happy to prepare it for you. Tell us what you need.

21 Apr 2014

How to share modules among several ORM Designer projects

In this short tip I want to show you how to share modules (plugins) bewteen serveral ORM Designer projects.

Save module to shared location

As first step you can create or select any module you want to share among several projects and double click on it. As the next step select “Files and export” tab and enter a path to the shared directory to the “Data storage” edit window. In our example we store shared module in the location c:\sharedlocation\ The situation looks as in our first screenshot:

Import existing module

As the third step, open any project where you want to use this shared module. After that, select “Attach existing ORMD file to model” from “Import” menu.

Shared module in another model

In “open file” window select shared module data file. In our case we select file c:\sharedlocation\ and click OK. After that shared module is attached to the model.


By using this technique you can share your models among several projects with minimal effort. Instead of repeatable creating of entities over and over again you can simply attach your shared modules to any project. And every change you create in the shared module will be automatically shared in all your models. This behavior can be used in any ORM framework (PHP Doctrine, Doctrine2, Propel or CakePHP).

17 Sep 2010

Posted by: Ludek Vodicka

Skipper tips #features #orm designer

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

New version notifier for ORM Designer

Another small improvement for upcoming new 1.4.x version of ORM Designer is a new version notifier. Here is a screenshot of this new feature:

16 Aug 2010

Posted by: Ludek Vodicka

Skipper features #features #orm designer

New feature for CakePHP users – DB Schema export

Today I would like to introduce you a new upcoming feature for CakePHP users. Nowadays ORM Designer can export php classes for your model objects. But when you want to use CakePHP migrations, you have to make the DB changes manually. This would change in the next ORM Designer release. Besides model classes ORM Designer knows how to generate CakeSchema ( object class which defines a whole DB structure.

Usage of this new function is very simple. In your current ORM Designer model choose “Project object”

CakePHP schema management and migrations

In Project property window there is a new item Schema with child export-file.  Select “export-file” property and click on the button with three dots and choose export file for schema file.

Export CakePHP schema file

Now, if you export your model by using “Export to ORM” button, beside the model object files DB schema file will be also generated.

For our example DB schema file will look like this:

/* SVN FILE: $Id$ */
/* App schema generated by: ORM Designer ( */
class AppSchema extends CakeSchema
  public $name = 'App';
  public $Contact =
    array (
      'ID' =>
        array (
          'type' => 'integer',
          'null' => 'true',
          'default' => 'NULL',
          'key' => 'primary',
          'length' => '4'
      'Name' =>
        array (
          'type' => 'string',
          'null' => 'true',
          'default' => 'NULL'
      'Age' =>
        array (
          'type' => 'integer',
          'null' => 'true',
          'default' => 'NULL'
      'indexes' =>
        array (
          'PRIMARY' =>
            array (
              'column' => 'ID'

Note: This feature will be available in and later.

05 Aug 2010

Support of CakePHP validators in ORM Designer

Today we finished beta support of CakePHP validators in ORM Designer. Thanks to Stefano Manfredini for giving us the idea and testing this new feature. You will find this new feature in upcoming ORM Designer 1.4.0 version build 417 and later.

Screenshot of testing model with entered validators:

Detailed screenshot to all supported validators in ORM Designer:

How to use it

If you want to add a validator to any field in your model, follow next instructions:

  1. Select the field where you want to define new data validation.
  2. In ORM Property window click on Validator item ->  ”Add Item”.
  3. After clicking on “Add Item”, the window with all supported validators appear. Choose the required validator and press OK.
  4. After selecting validator from the list, you can add some additional parameters.  You can do this by selecting  added validator and entering value to the correspond property.

After you enter all required validators, you can “Export” them to base class.

And it’s done. No more complicated and confused array definitions, simple design it in ORM Designer ;-)

List of currently supported validators include their parameters:

  • alphaNumeric
  • between
    • minimum
    • maximum
  • blank
  • boolean
  • cc
    • type
    • deep
    • regex
  • comparison
    • operator
    • value
  • date
    • format
  • decimal
    • decimal
  • email
    • validate-host
  • equalTo
    • value
  • extension
    • value
  • ip
  • isUnique
  • minLength
    • value
  • maxLength
    • value
  • money
    • position
  • multiple
    • in
    • min
    • max
  • inList
    • values
  • numeric
  • notEmpty
  • phone
    • reg-ex
    • country
  • postal
    • reg-ex
    • country
  • range
    • minimum
    • maximum
  • ssn
    • reg-ex
    • country
  • url
    • strict
  • reg-ex
    • regex
  • own-function
    • name
    • params

All validators have folllowing commont properties:

  • name: Rule name used in definition array when field has multiple validators
  • required: Require flag, for more information follow CakePHP documentation.
  • allowEmpty: AllowEmpty flagfor more information follow CakePHP documentation.
  • on: Validator type. Can be NULL/create/update. For more information follow CakePHP documentation.
  • message: Error message for the rule.For more information follow CakePHP documentation.
  • last: Flag used when one field have multiple validators. More information about last flag in CakePHP documentation .
18 Jul 2010

Inheritance support in ORM Designer

One of other major features introduced in ORM Designer 1.4.0 is inheritance support. Currently supported frameworks are PHP Doctrine and Doctrine2.

There are several ways how to create inheritance between entities.

1) Inheritance tool

If you want to use inheritance tool, first select this tool on the ribbon window:

With this tool selected click on base entity from which you want to inherit.

Next click on entity that should be derived from base entity.

Once the inheritance is created, you can configure more parameters in the Property editor.

2) Inheritance wizard

If you want to use inheritance wizard, select entity in model and use “Create Inheritance”command from ribbon tab “Editing”.

In the Create New Inheritance wizard select base and derived entity from the list of entities in the combo boxes.

You can also select type of inheritance, discriminator field and discriminator value for created inheritance.  More information about additional parameters is at the end of this article.

3) Create inheritance in project tree

You can also create inheritance through project tree. Simply select entity (which will be used as the base entity for inheritance) in the project tree and select “Add Inheritance” in the context menu (right-click on the entity).  New inheritance wizard will be executed after this step (same wizard as in previous step).

4) Create inheritance in entity edit window

Another way how to start “New Inheritance Wizard” is through the edit entity window. Select “Inheritance” tab in the “Edit entity” window. In this tab select “Add Inheritance” from top tool bar to start “New Inheritance Wizard”. This tab also contains list of all extending and base entities.

Inheritance Additional parameters

Type of inheritance is ORM framework dependent. For PHP Doctrine framework is available Simple inheritanceConcrete inheritance or Column aggregation inheritance. For Doctrine2 is currently available Single table inheritance  and Class table inheritance.

Note: Mapped superclass isn’t currently supported, because there is no way how to define it in YAML or XML file format.

13 Jul 2010

Inheritance in ORM Designer – First screenshot

One week after first ORM Designer 1.4.0 public beta release we’re finishing full support of Model Inheritance. Inheritance will be available for Doctrine and Doctrine2 ORM frameworks. Within a few weeks we want to implement inheritance support also for the new version of Propel 1.5..

Bellow is a screenshot of simple model with inheritance and association. On the right side of the screen is a detail of inheritance editor.

05 Jul 2010

Updated Doctrine association property editor

ORM Designer 1.4.0 is almost here and we want to give you yet another peek of what is coming. ORM property editor is the core feature since the first release of ORM Designer but it can be sometimes hard to use and understand which values to fill. Especially association configuration (“alias” / “foreignAlias”, “type” / “foreignType”, “cascade” / foreignCascade”) was one of these cases. Some of these association properties were side-dependent and others were  same for both sides (in Doctirne ORM for example database attribute “onDelete”). From now on you’ll find side-dependent properties grouped by owning-side and inverse-side with destination table hint for better orientation.

ORM Designer screenshots

On the left side is old version, on the right side new one.

ORM Designer 1.3.x

New property editor in ORM Designer 1.4.x

On the left side is old version, on the right side new one.

Detailed screenshots of side-dependent groups with selected direction assistant:

26 Jun 2010

New Doctrine 2 object properties editor

When we started implementing Doctrine 2 support we had to deal with many new ORM framework features. Doctrine 2 has many new associations and the association definition is more descriptive than before. To solve this problem we hacked the powerful ORM property editor. Bellow you can see some of the new features. You get direct configuration of object properties with predefined values and validators. And as you are used to from Doctrine 1, Propel and CakePHP you get inline help on the places that might be confusing.

ORM property editor object and field:

Doctrine 2 object property editor

Doctrine 2 field property editor

Property editor example of one-to-many association and many-to-many association:

Doctrine 2 association properties

Next step before releasing public version is ORM and ERD terminology unification. It’s a bit confusing in current versions when you are editing ORM application model and all model components are named as you are used in ERD (e.g. on the first screenshot is “object” still called “table”. Relation is called “foreign-key”,…).

21 Jun 2010

Posted by: Ludek Vodicka

Skipper features #orm designer

First ORM Designer Doctrine 2 project screens

After serveral weeks of intensive work on ORM Designer we’re almost done finishing Doctrine 2 support. You can find two new screenshot bellow with correctly imported Doctrine 2 model. Used models can be found in Doctrine 2 unit tests.

First alpha version is almost ready to be released, we have to do some final touches to the user interface.

Screenshot of CMS testing project:

Screenshot of Navigation testing project:

Screenshot of import project screen in ORM Designer:

18 Jun 2010

Updated property editor in ORM Designer 1.4.x

In this post I want to show you one of the new features to be released in ORM Designer 1.4.x. ORM Designer works differently with core properties and ORM framework dependent properties. This is due to different features provided by ORM frameworks. For example column core properties are name, type, length, description etc. and ORM properties scale and unsigned in Doctrine ORM.

With the coming release of ORM Designer with Doctrine 2 we have to do refactoring of many windows. Also some of the properties previously located under ORM dependent properties would be moved to the core properties. As a result you should be able to faster and easier define foreign and local alias of relationship/association and other common tasks. As this would be a change in the way you were used to work before we wanted to make sure you’ll find what you are looking for. We’ve merged core properties and ORM dependent properties into a single window so you could see all applicable properties at the same place.

Here are some screenshots:

First screenshot shows editing module in Doctrine ORM project, second screenshot is active property editor editing objects column.

08 Jun 2010

Posted by: Ludek Vodicka

Skipper features #features #orm designer

New error handlers in ORM Designer 1.4.x

One of new features in upcoming ORM Designer 1.4.x will be updated error handlers. No more old unmeaning error boxes with short message. New handlers will have intuitive gui with well arranged controls.

ORM Desginer exception - summary

Log Output

The main change will be a new Log output tab where user will found detailed information about raised exception. This tab will contain more detailed information about the error or raised exception. When user will work with new ORMD script system and running script will cause the error, this tab will contain the log of script execution with all variables and their values.  (Script system is also developed for 1.4.x version, more about it in next post).

ORM Desginer exception - show log

02 Jun 2010

Posted by: Ludek Vodicka

Skipper features #features #orm designer