This concept page is to discuss the topics that are shared between ConfigByCode and ConfigByFile.

Purpose

People have problems working with repository configuration, as illustrated in this forum post: https://forum.magnolia-cms.com/forum/thread.html?threadId=dacbff3f-0ce9-4293-b8b2-b5c1843568b7

1. it’s an anti-pattern that changes made in adminCentral are not in your “project”. 

It causes additional work & potential headaches/mistakes:

  • You must export configuration changes  to bootstraps. You might forget.
    These changes should be commited to version control with any relevant code changes.

  • Others must import bootstraps or reinstall modules. They might forget.

  • You must write module version handlers to handle the configuration changes on update.
    As an example of how this is problematic for some teams - one team chose to work with one development server, just so their configuration would be in synch.

2. The workflow for configuration is different then that for code & templates, which slows down productivity.

3. Some developers like to work in their IDE (where they are familiar and productive), rather than a new web UI.

4. Reasoning about configuration in the repository is difficult because it behaves differently than code (ie it is persisted).

5. Bootstrap files are hard to read, edit & merge changes on.

Analysis

ConfigByFile vs ConfigByCode

We find that there are significant benefits for both of these approaches and therefore intend to implement both. Much of the underlying code & mechanisms will be used by both approaches.

Key Benefits

  • ConfigByCode
    • IDE support such as Autocomplete.
    • More powerful configuration as it can be manipulated - for example configuration could be optional based on other conditions or configuration.
  • ConfigByFile
    • Javafree: Usable by non-java developers, and within javafree modules.
    • Exportable from existing configurations in AdminCentral.
    • Potential IDE support if we use an XML format via XML Schema, or JSON (autocomplete, validation)
    • Configuration Hierarchy is clearly visible (Simlar to the treeview in adminCentral).

Implications

Moving to "Volatile Configuration" means that the repository does not store ALL of the information needed for the running website. So pushing a website from an author to publics must change to accomodate this. We should at least CONSIDER a mechanism to push Config stored in files or code from public to subscribing servers.

Considering implications of ConfigByX

ImplicationsCurrent: Config in AdminCentralProposal: ConfigByX 
UI

See the entire running configuration.
Search the running configuration. 
Access it from anywhere by website.
Easy to find.  
Could provide dialog/wizards.
Could provide help.
Could provide "extends insight" - tooling to understand extends.
Could be linked to from other apps, like Page Editor. 

Have multiple files (views) open.
Copy & paste
Same familiar work processes as templates & files
 

 
Instant updatesChange the config of ANY module.
Instantly see the impact.		Change only your module.
Would need tooling to reload changed config file. 		 
Version ControlPain that you have to export (often forget)
Bootstrap diff / merge are difficult to understand
Pain to apply changes from others - import / reinstall. 		Seamless, works like other files. 
Module version updates MVHPain to write & test & review.Not necessary. 
UninstallNo clean uninstall.Uninstall would be easy because configuration of other modules was not overwritten. 
Changing config of other modulesYes.Yes. You could create a file that overwrites the changes from other files. 
Agile changesYes.Would require additional changes to distribute files. But one could still edit the config tree directly. 
Deployment   
Publishing What to publish? The ConfigFiles as well? Must you push new Jars? Could you publish the "active configuration"? 

 

Resources 

Etcetera

How can we ensure that edits via an AdminCentral app are not overwritten by ConfigByX at startup?

  1. Handle it like Inplace Templating: An extra property on the changed node, "preserve=true" prevents the ConfigByX from overwriting that node.
  2. ConfigByX is appllied first - then repository is applied on top of it.
  3. Or, all manual changes are actually written to yet another repository: "overrides".
    • These changes are applied to the active configuration after ConfigByX runs. 
    • Benefit: With additional tooling: it would be easier for a user to see what manual changes should be merged back to files in source control.

  • No labels