This is the entry point for the whole Config By X theme.

What does it mean

Config By X means that configuration for magnolia can be provided by different means - no longer only by jcr as today. Independently from how it's actually provided these configurations will end up in memory.

 

The Pieces

Config By X basically consists of the model (interfaces + definition classes) as well as the various mechanisms to populate the module (from JCR via Node2Bean, by Code via builders or by file via a new mechanism).

Contents:

  • No labels

1 Comment

  1. Tobias Mattsson

    Things to consider:

    Tools

    While discussing the topic is been mentioned multiple times that we'll need some form of tooling to visualize the configuration to show the entities that have been configured, where they came from and how and by whom they were modified. We might need to track this on the entities themselves by recording the source and adding tracking information as it is changed. See decoration below. It would be cool if the STK template prototype was visible in the tool. It will be difficult to show entities that behave differently based on circumstances such as what a dialog is shown for, think configuration by code and if statements in the code.

    Decoration

    Entities (dialogs, templates, apps etc) are configured / installed by modules as they're installed in the instance. Modules are installed in an order based on their dependency graph. This allows a dependent module to alter an entity installed by a module it depends on. It can overwrite, change or delete the entity. It is usually done by update tasks in the modules version handler. New configuration styles must use the same order to resolve name clashes and allow decoration (alterations) in the same order. That is, if module A installs the entity and module B and C changes it then the order that B and C are applied must be determined by the module install order.

    Definition objects are currently held in memory and all code use the same instance. Depending on the implementation this might need to be changed.

    Decoration requires some kind of matching. In the simplest case matching by exact name, other cases would be to select all dialogs, or all dialogs from a certain module.

    Decoration should be possible on entities configured using a different configuration style than the decorator itself is in. I.e. work on both config-by-code, file etc.