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

Tag: #propel

New namespace support in Skipper

Our latest release 3.2.0 brings to Skipper new way how namespaces are handled by our application.

Few words about history

Long time ago when the first version of our application was created (originally called ORM Designer), there hadn’t been things like namespaces in ORM frameworks. But as ORM frameworks have been developed in time, each framework came with some way how entity namespaces are being handled.

Because ORM Designer / Skipper needed to handle it too, we added support for namespaces in form of ORM attributes. This had been a functional and sufficient solution until Doctrine 2 has introduced new way how to handle namespaces and allowed several entities with the same name but in different namespaces.

For some time it wasn’t possible to create such models in Skipper because of internal limitations (each entity was represented by it’s local name only). But today with our latest release this limitation is over. We have reworked Skipper core and a way how unique names are handled and now it’s possible to create also these models.

New age of namespaces

Starting with version 3.2.0 each Module, Region, Entity and Collection can have defined its own namespace

Skipper region namespace settings

Namespace of each object is calculated from all its parents:


Each of these objects can have defined own relative or absolute namespace. This means that in case of need sub-region can override namespace via absolute path. In such way, the final entity namespace will be:


The same thing is possible also for Entity. In case you need to define one of your entities in different namespace than the rest of entities in the module, simply define absolute namespace directly for the entity.

New namespace system in Skipper

All this features are available to all ORM frameworks which support namespace. Namespace support is available for all import and export scripts as same as for visual editing.

Project file changes

Because of these changes it was necessary to update Skipper project files a little. There are two most important changes which caused that projects from 3.2.0 aren’t fully backward compatible with older versions.

The first change of XML format are new attributes @local-name, @name, @local-namespace and @namespace. Attributes starting with @local- are values defined on specified object. On the other hand attributes @name and @namespaces are calculated values depending on its parents.

The second change in XML format is deprecated <entity-ref> and <collection-ref> elements in project file. Instead of __ elements entities are stored in owner regions to keep the same hierarchy like in visual model.

For example, this means following. This is how looked original project file with entity in one region like:

<module name="module">
  <region caption="test">
     <entity-ref name="e1"/>
  <entity name="e1"/>

And this is how project file looks like now:

<module name="module">
  <region caption="test">
     <entity name="e1"/>


Although it might not be visible on the first sight, new namespace support was a very complex task. Because of that we had this feature for more than month in beta mode before releasing it to public. Thanks to all our testers we successfully localized and fixed several bugs caused by this new feature.

Now, when no more issues are reported we decided to publish it for all our users. We will be glad for any feedback.

Let us know how you like it!

Propel ORM Behaviors support!

Note: This feature is currently available only in beta-version 1.4.5. If you want to try it, please download latest version from

Another news for Propel ORM users! Today I want to introduce you new Behaviours support feature.

ORM Designer supports two ways how to handle behaviours. The first way uses predefined behaviour list of already known behaviours, the second way uses customBehaviour type to define any behaviour by it’s name and params.

Use of custom behaviors

For setup custom behaviour to any of your tables, follow next steps:

  1. Mark the requested table
  2. In ORM Properties list click “Add item” next to “Behaviors” property Propel ORM custom behaviors
  3. Select “customBehavior” from the list Propel ORM custom behavior
  4. Enter behaviour name to relevant “name” property Configure custom behavior name in Propel ORM
  5. If your behavior has some parameters, add them by using “Add item” next to “CustomParameters” property Custom parameter for ORM Propel behavior
  6. After that you have to enter the parameter name and the parameter value. You can add unlimited number of additional parameters. Configure custom param value in Propel ORM behavior
  7. And this is it ;-). Now when you export your model, you can see definitions like this:

Use of predefined behaviours

Using of predefined behaviours is better than custom one in several ways. As first, you don’t have to write behavior name again and again but you can simply select it from a list. The same thing is for the behavior parameters. The second advantage is that for specific parameter values there is an automatic completion and offering of preferred values (booleans, column names, … ). Now I show you how to define “Timestampable” behavior for a specific entity.

  1. The first steps are the same as in the previous example. Select the requested entity, click “Add item” next to “Behaviors” property and select desired behavior. In our example “Timestampable”. Propel ORM timestamplable behavior
  2. Now you can configure timestampable behavior by using two predefined properties “create_column” and “update_column”. When you click on the arrow next to property value, you can simply choose the one of available columns. Timestampable behavior Propel ORM
  3. Each predefined behaviour has also an option to define another additional behaviour parameter. This can be simply achieve by using “customParameter” as well as in the case of the custom behaviors. Custom property for timestampable behavior
  4. When you add one or more custom parameters you can simply configure them. Custom property for Timestampable behavior

List of currently supported Propel ORM behaviors:

  • NestedSet
  • SoftDelete
  • Sluggable
  • Timestampable
  • Sortable
  • Aggregate
  • Versionable
  • I18n
  • Query Cache
  • AutoAddPk
  • Alternative Coding Standards

Note: Remembr that you can anytime use customBehavior if you need to use behavior not listed in list above. If you find any behavior which is common for more users and isn’t listed here, let us know and we will add it to ORM Designer configuration.

I hope you like this new function and as always if you find any bug or have any idea feel free to let us know!

27 May 2011

Posted by: Ludek Vodicka

Skipper features #features #propel

Propel ORM validators support!

Note: This feature is currently available only in beta-version 1.4.5. If you want to try it, please download latest version from

While working on a new ORM Designer version we prepared one significant improvement of the current ORM Designer version for all Propel ORM users.

From now, ORM Designer natively supports all Propel core PHP validators mentioned in the documentation.

The usage is simple, as usually ;-). Create an object, add few fields and commit changes. Then select desired field of the model and look to the ORM Properties editor:

Propel PHP validator

Now, when you click on the add icon you can choose from the list of available validators or choose one of two special items “otherValidator” or “customValidator”:

List of available PHP Propel ORM validators

  • OtherValidator use in special cases when you want to use validator which isn’t listed in this list. This validator choose if you would like to enter all validator identificators like name,value and message and these values will be added to the specific column.
  • CustomValidator is there for cases when you have implemented your own validator and want to use it in a specific column. In this case simply add a class name to this validator and ORM Designer will export it for you.

You can have zero,one or more validators of one type for one column because of multiple instances of custom or other validator. Here are few examples of already configured validators:

Other Propel ORM validators minLength, maxValue, match Propel ORM Validator

Now, when you press “Export” button, your XML file will look like this:

Propel ORM XML file

Note: Validators aren’t supported for YAML export, because there isn’t support in Propel ORM! (there is link:

05 May 2011

Posted by: Ludek Vodicka

Skipper features #features #propel

New tool - ORM Designer

ORM Designer released

ORM Designer

Today we have officially released our application, ORM Designer, to public. For more than 3 years, we have used it as an internal tool for our Symfony and Propel/Doctrine based commercial development. Since it helped us a lot, we decided to offer it to more users.

ORM Designer will allow you to design your schema definitions using ER diagrams. You won’t have to write your XML/YML definiton files manually from scratch. You won’t have to keep up-to-date documentation and diagrams in another tool. Everything will be in one place: you will design your models visually in ORM Designer, and ORM Designer will then generate the code.

Try our application out, you will like it. And let us know your comments or ideas, we are interested in your opinions.

Application is offered for a starting price of €99. This includes a year of support and updates for free. After this period,  you can extend your maintenance for another year. Each extension will cost 30% of the original price.

05 Dec 2009

Posted by: Ludek Vodicka

Skipper features #doctrine #tools #propel