MODULESTUDIO

The core version 1.3 of Zikula now ships the ORM layer called Doctrine. Because of this we completely overhauled the data layer in ModuleStudio to precisely express the different concepts and functions available in Doctrine. This article deals with the essential aspects for modeling Doctrine artifacts and demonstrates relevant specialities. Prerequisites for the full understanding of this articles are knowledge of Doctrine terms, as well as the tutorials for describing the model and about the structure and customisation of generated applications.

From each entity in the data layer there are classes for records, table and event listeners created. Therewith the single fields as well as their properties are accordingly interpretated. For many data types and basic properties, like unique, readonly or notnull this happens with a one to one adaption. Several things are shortened for convenience in ModuleStudio though. Furthermore there are some additional data types, like for example for users, email addresses, urls and uploads. An email field is treated by the generator as a string field in Doctrine which has the email validator activated.

Validators are generally not explicitely modeled in MOST, but simply defined with properties. So there are for example attributes like notspace, country, ipaddress or htmlcolor for string fields. Timestamp fields have according properties for past and future, for Integer fields there is a creditcard property beside others. Individual check constraints were not considered at all in ModuleStudio yet, because they are not portable anyway. Indexes are naturally supported though.

The different types of relations in Doctrine are all offered, too. For inheritance relationships the strategy can be selected (Simple, Custom, Column Aggregation). All other connection types store a name for the two entities on both sides (Source Alias and Target Alias) as well as the referenced fields (Source Field and Target Field). Because the primary id fields of entities are not modeled, but automatically added before the generation, the string „id“ is allowed and also set per default. By changing these fields it is possible to describe also relations referencing other fields. Beside this it is possible to have multiple relationships between the same entities and also self relations, only the alias settings must be unique. Finally one can also define how the cascading behaviour should look like. Also here all options offered in Doctrine are supported.

The properties of an entity itself contain the table type, collation and encoding. Those properties involve also settings regarding behaviors. Therefore it is important to mention that one has to specify for several behaviours which fields are affected. For example this is the case for Versionable, I10n, Searchable and Sluggable. For each of them there exists a corresponding property for storing names of the desired fields, separated by a comma with space. For some behaviors special fields were not added, for others a selection of all options has been provided. If missing fields should be relevant often in practice they can be added without problems. Beside the core behaviors of Doctrine the entities do also have some Zikula-specific additions by the way, like the behaviors Attributable, Categorisable, Loggable, MetaData and StandardFields.

The modeling of own event listeners is planned and the language elements are already existing, but they are not yet integrated in the editor. Base implementations for all record listeners supported by Doctrine are already generated though.