Tag: #propel

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

Namespace of each object is calculated from all its parents:

\Module\Region\SubRegion\Entity

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:

\SubRegion\Entity

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.

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:

Conclusion

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.

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

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:

Mark the requested table

In ORM Properties list click “Add item” next to “Behaviors” property

Select “customBehavior” from the list

Enter behaviour name to relevant “name” property

If your behavior has some parameters, add them by using “Add item” next to “CustomParameters” property

After that you have to enter the parameter name and the parameter value. You can add unlimited number of additional parameters.

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.

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”.

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.

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.

When you add one or more custom parameters you can simply configure them.

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!

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:

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”:

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:

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

ORM Designer released

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.