ModuleStudio 0.7.5 has been released

ModuleStudio 0.7.5 has been released pdf

The version 0.7.5 of ModuleStudio is now available for download. Beside a number of corrections several changes and innovations are contained. The tooling is now based on Eclipse Oxygen and brings an overhauled properties view: the properties of an element are clearly separated into multiple tabs:

  • General: basic settings like name, documentation or length of a field.
  • Constraints: restrictions for validation, for example a minimum width for an image upload field.
  • Behaviour: all aspects relating functional enhancements.

Each tab may contain one or multiple sections which can be collapsed and expanded. For example below the normal fields often exist expert settings which are collapsed by default. So the view is basically more tidy which simplifies orientation particularly for newcomers.

preview

Changes in the DSL

The new default target version is now Zikula 1.5. Support for Zikula 1.4 has been marked as deprecated and will not be contained in the next release anymore. Thus a warning is shown if a model still gears on Zikula 1.4.

For string fields there have been a range of checkboxes for different special field types (e. g. BIC, Country, Locale, and so on). These have been replaced by a new role property represented by a select widget. While models with the old flags can still be opened, these properties are not migrated automatically. This means that the role must be set to the desired semantics for existing fields.

Furthermore the validation of inheritance hierarchies has been improved. Miscellaneous checks, e. g. for duplicated fields and actions, field references in display patterns, missing fields or actions, have been adjusted to consider inheritance correctly. Also the generator got several improvements with regards to inheritance by the way.

Enhanced hooks support

One of the most comprehensive innovations concerns the extended support for the hook system of Zikula. So far generated applications already supported the so-called hok subscriber functionality in it's different manifestations. This means that on view and detail pages as well as in editing and deletion forms functions from other modules (hook provider) could be integrated in order to attach for example comments or incorporate WYSIWYG editors. Apart from these UI hooks also subscribers for filter hooks have been generated; therewith data can be arbitrarily filtered to realise censorship functions for instance.

In Zikula core 1.5 two aspects of the hook system have been expanded: first the information about subscribers and providers does not need to be persisted in the database anymore (non-persisted hooks), but is defined using Symfony tagged services. Second there is a new third hook type: with form aware hooks extensions can be integrated within Symfony forms. ModuleStudio now also generates the corresponding subscriber into applications for Zikula 1.5 and 2.0.

The distinctly more weighty amount of innovations however concerns the hook provider support - for Zikula 1.5 and 2.0 also, but not for Zikula 1.4: in a model's generator settings can be configured whether a filter hook provider and/or a form aware hook provider is wanted. The generator creates valid provider classes with dummy functionality which can be very easily extended and customised for both hook categories. The UI hooks provider can be activated for each single entity and there a lot more happens in addition: there are means generated to search entities using auto completion and attach them to the activated hook subscriber areas which also includes the inline creation (and automatic assignment) of new entities in a modal window. All assignments are stored in an additional database table so it is possible to attach the same entity to several different data objects (for example an image could be added to three news articles). Owning data objects are linked from the entity display pages, too: so one can for example switch from a comment to the page for which the commend has beeen created for. Existing assignments are automatically removed when the owning data object is deleted or the owning module is removed from the system.

All changes in detail can be checked in the changelog.