Category: Hints for developers

One of the main strengths of former ORM Designer and now Skipper is the ability to display project visually in easy-to-orient and easy-to-read form. Although modules and regions help in this regards, with growing number of elements in the model it was sometimes challenging to know which association went where. And some people may prefer not to use the option to split the connectors of associations.

That’s why we added new feature aimed at improving the overall model clarity even further:

Colored entities

Attentive spectators surely noticed new tab named “Appearance” in entity editor. Here you can change header entity color, as well as background color. In case you will want to you can also change them back to predefined default colors.

From now you can customize your model so it might look for example like this one.

Colored associations</h4>

As well as you can change the colors of entities, you can also change the color of associations. You can find the option for changing of colors as a second item in General Settings.

So in larger model you can distinguish your associations so you can simply follow connections between entities.

Auto-coloring on import

Coloring of the association might be useful also while importing existing project into Skipper.

To turn this option on just check the option to “Use colors for imported associations” in Import wizard. This will automatically color every association, so you can easily orient in your generated model and it saves you from the necessity to do it manually later.

Wouldn’t it be cool to have the most commonly usedORM functions and definitions clearly described in one place? Of course, for the developers using ORM Designer, no such thing is necessary, everything is handled by ORM Designer. For everybody else we decided to create ORM Cheatsheet - the simple and clear manual.

ORM Cheatsheet is divided into several sectionsaccording to the frameworks. For the beginning, we made sections for frameworks that are the closest to us like Doctrine and Doctrine 2, but we plan to cover more frameworks and you can even add another framework (or anything useful) by yourself.

Doctrine and Doctrine 2 sections describe installation, configuration andbasic usage** of these frameworks and usage with Symfony or Zend Framework. You can also find there model elements in XML, YML and annotation** format together with its visual model preview. Pages also summarize popular Gedmo extensions for Doctrine 2, ORM Designer usage with ORM frameworks and of course links to interesting resources on the topic.

ORM Cheatsheet is a community project for PHP developers using ORM frameworks and everyone can participate in extending it. If you would like to join and contribute with anything useful contact us on email [email protected] or fork ORM Cheatsheet on Github.

For Thursday April 17, 2014 meeting of local PHP community is scheduled in Brno (CZ) and we will be there too. You can meet people of same interest, listen to talks and chat with others. These PHP events take place roughly every two months.

Because we love to support local community, we became the main partner of the event and each participant can attend in raffle for the full license of ORM Designer. Our colleague, František Tröster will have at this event presentation how to speed-up development with ORM Designer.

There will be 4 talks, 25 minutes for each:

18:20 What makes a good developer from a management perspective (Marek Šudák)

19:10 WebSockets - how to do real-time applications in PHP (Ondřej Mirtes)

20:00 ORM Designer: Speed up your ORM development (František Tröster)

20:50 How to parallelize in PHP and not go crazy (Martin Strouhal)

Entry is free and attendees will have food and beer gratis. If you are interested in this meeting, do not hesitate with the reservation, number of participants is highly limited.

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.

Quite a lot of people asked us about how ORM Designer2 insides work. Some wanted to customize it, some were asking because they were curious about some future features. So I decided to give you exhausting inside look:

Historic background

We have first thought of ORM Designer as a tool to help us with our work at that time, web sites and e-commerce. I spent a lot of time thinking about how to deal with definitions in different formats. In those early days only Doctrine and Propel were in widespread use. So we only needed to work with YAML and XML, and the file structure was also quite simple: one module = one file.

First version was really rudimentary, compared with the latest ORM Designer2 version. Whole import/export logic was hard-coded in the application itself. But as ORM Designer grew in complexity, it became necessary to customize and expand import/export process. To deal with it, we have created our internal XML scripting language (in version 1.2). While still pretty basic, this internal language helped a lot in further expanding ORM Designer.

With the Doctrine2 we have met series of big challenges. Most notably need to import/export each entity as a separate file, and need for native support of annotations format. To implement these changes, we decided to rework the application completely.

ORM Designer 2 comes in January 2013. Application is completely redone using Qt framework. Now, ORM Designer not only becomes multi-platform, but the focus was also on the maximum modularity and possibility to expand and customize the whole application. With the new version comes also the support for the annotations format.

Dealing with different formats

As you know, ORM Designer 2 supports three different formats for the definition files: YAML, XML and PHP annotations. To process such different formats, all the files are at first transformed into XML. Its easy for XML files :). And its pretty straightforward for YAML. The PHP annotations require an extra parser which transforms the PHP file to the AST (abstract-syntax-tree), and this tree is subsequently transformed to the XML format.

XSLT transformations</h4>

Now, we have the input in the XML format, but the content of the file is still dependent on the original file format. These XML files are transformed using specific XSLT template and the result is the so called abstract-XML. This file contains all the information of the input file, but its structure is unified and format independent.

Last step is to transform the abstract-XML to ORM Designer project file. The project file is a regular XML file with additional information for the model layout. This file is loaded by ORM Designer, but can be as easily edited manually.

Export uses the same principles, only in the reversed order: from ORM Designer project file to abstract-XML, then to XML files that have the structure representing the final output format, and in the end the actual definition files are generated.

ORM Designer import process

Scripting

Another crucial concept in ORM Designer is the scripting support. Because every ORM is different, different way of processing and different number of transformations is required. To accommodate this, we have implemented the JavaScript support together with a few script extensions.

This scripting allowed us to easily describe the transformation process in required detail for each ORM Framework individually. Its even possible for users to tweak and extend the import/export script as much as they want.

Scripting is used for import, export and directory lookup prior to the import. I have plans to expand ORM Designer functionality in the future. Users then should be able to write and launch their own scripts directly from the ORM Designer GUI.

Annotations

Annotation support is very different from the way XML/YAML files are processed. Annotation source files needs to be parsed into individual language elements. These elements are then organized in the AST (abstract syntax tree), which represents the information and logic stored in the code.

The AST is then further parsed and only the Classes, Attributes and their annotations are kept, the simplified syntax tree is created. Simplified syntax tree contains only ORM specific information. This simplified tree is finally transformed to the XML and further processed using XSLT transformations.

Because the annotations contain further information apart the ORM specific code, the export is even more complicated. The import process is reversed: from ORM Designer project file, through abstract XML to AST. But now comes one extra step.

Second AST is created from the target file and it is compared to the AST created by the export process. These two trees are then merged, so that only changed or newly added ORM annotations are modified. This ensures that no other part of the original file is modified or removed.

Few words at the end

I hope this article helped you to take a peek on the insides of your favorite software. If you are more interested in the inner workings of ORM Designer, tell me in the comments below.

In simple words are wireframes models of web pages or applications that describe their content and function. While it’s not a full prototype, there are no colors and concrete pictures. Wireframing is a very useful activity simplifying communication between the submitter and implementer of the application itself.

Do you use wireframes or mockups for designing websites and applications? Do you have a favorite tool for this task or are you a hand drawer?