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
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:
<module name="module">
<region caption="test">
<entity-ref name="e1"/>
</region>
<entity name="e1"/>
</module>And this is how project file looks like now:
<module name="module">
<region caption="test">
<entity name="e1"/>
</region>
</module>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.
Let us know how you like it!
