Tag: #doctrine

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.

We asked our developers, who to follow or what to monitor on social networks and where they find new tips and current topics in their field of interest. Based on their references we compiled a following** list of interesting people and accounts** of various PHP frameworks or debating communities for selected social networks:

If you are a Symfony beginner or daily user the summary of most used tasks for this PHP framework will make your work easier. The Symfony2 Cheat Sheet is made by David Perez, who is experienced Symfony user and web developer from Spain.

He put together a sophisticated guide full of descriptions, sample codes and functions for most used principles in Symfony framework. Among other things there is in clear way explained controller, routing, templating, testing, validation, forms and security. But for us the most valued is a section about how to use ORM Designer with Doctrine project.

This section guides Symfony users step-by-step through creating or** importing** of Doctrine project into ORM Designer. There is mentioned how to** manage basic objects** like entities, associations or properties. You can also read how to export definitions to Doctrine, which comes in one pack with Symfony2 framework.

ORM Designer is described as a modelling tool allowing to start using Doctrine without deeper framework knowledge. In this Doctrine section is also highlighted comfortable way of work with the project and pointed out ability to continuously export the Doctrine definitions from the model.

Since we consider Symfony2 Cheat Sheet as very educational and useful project, we provided David with full ORM Designer lifetime license for free. Symfony2 Cheat Sheet is a nice summary and represents inclusion of ORM Designer in development process that is worth of pinning in a visible place.

Today I want to show you a new feature of ORM Desigener for Doctrine ORM. It is an ability to define prefix for a whole module by which ORM Designer exports every entity with a name composed of this prefix and stand-alone name. In the past we received several requests from Zend Framework users for this feature, so here it is ;-).

This feature is the most useful for Zend Framework users, but might be used by every Doctrine ORM user. When using Doctrine ORM with Zend Framework you have to create the names of your entities with prefixes as Default_Model_Entity_Name or Forum_Model_Entity_Name (more about this topic is described in the article Doctrine1 Integration with Zend Framework).

And how does it work? Here is a screenshot of an example model:

In this model we’re using simple and nice entity names like “parent” or “child”. To “entity_prefix” attribute of each module we enter common prefix for all entities. After that when we export the model to the YAML file, we get a following result:

In this tip I want to show you how to correctly setup associations in ORM Designer Doctrine2 project. Because Doctrine2 supports one-way or bidirectional associations, there is a need to tell ORM Designer how to export it. This is proceeded by Association alias. When you create association between two entities, you have to enter how you would like to access from one entity to another. Currently there are three ways how to do it:

Setup alias in association wizard

When you are creating a new association by using association wizard, you have to enter alias for direction you want to use. Below the alias edit boxes is a “Direction” item which shows you a type of created association.

Setup alias in association editor

Another option is to setup association alias in association editor (executed by “Edit object” menu item or simply double click on the association). In this window there are simmilar edit boxes as in the association wizard. Depending on values you entered into edit boxes the association is exported to your Doctrine2 schema files.

Enter alias using Property Editor

The third option how to setup association alias is in Property editor. Simply select the association you want to setup and in Property editor enter Owning alias or Property alias value.

Conclusion

I hope that this tip will help you to understand a way how ORM Designer proceeds associations export. Because Doctrine2 supports multi-direction associations, it is required this “Alias-enter” step. Please, leave us your comment about this feature if you have any opinion.

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 inheritance, Concrete 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.

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.

The simplest way how to start using ORM Designer with your current Doctrine2 model is to use an import doctrine2 model function. Currently is available only import from Doctrine2 XML schema files. If you have your model defined in anotation or using YAML files, please convert it to XML files. After that, follow next step-by-step instructions.

Import a new project from ORM

In a ribbon menu select Import New… and then Import Project from ORM.

In Import Project Wizard choose your project name and a root directory of your project where are your Doctrine2 XML files stored. As MVC framework choose Without Framework and as ORM choose Doctrine2 as shown on this screenshot.

After an import confirmation ORM Designer starts searching for your files and import them to new ORM Designer model.

In our example we import unit-testing model from Doctrine2 repository called CMS. When import procedure is over, you will see model like this.

After that you can start enjoying ORM Designer in your work with Doctrine2 model.

## More details about using ORM Designer with Doctrine2

Using of Doctrine2 in ORM Designer is very similar to using ORM Designer with PHP ORM Doctrine framework. For more information please look at ORM Designer and Doctrine framework page.

Supported Doctrine2 properties

Currently ORM Designer supports all properties from Doctrine2 except inheritance, which will be implemented during next months. All supported properties are based on official Doctrine2 XML schema. You can edit all properties simply by selecting the object and enter value to correspond field.

There are lot of properties which can be edited for every type. Here are screenshots of property editors for entity, field, association, many to many association.

Appendix: Currently unsupported features for Doctrine2

ORM Designer currently doesn’t support inheritance in any level of designing (visual, editing, import, export).
Iheritance for Doctrine2 and other ORM frameworks will be implemented in next few months.

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.

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:

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.