This concept page is to discuss the topics that are shared between ConfigByCode and ConfigByFile.
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.
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.
- 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.
- 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).
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
|Implications||Current: Config in AdminCentral||Proposal: ConfigByX|
See the entire running configuration.
Have multiple files (views) open.
|Instant updates||Change the config of ANY module.|
Instantly see the impact.
|Change only your module.|
Would need tooling to reload changed config file.
|Version Control||Pain 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 MVH||Pain to write & test & review.||Not necessary.|
|Uninstall||No clean uninstall.||Uninstall would be easy because configuration of other modules was not overwritten.|
|Changing config of other modules||Yes.||Yes. You could create a file that overwrites the changes from other files.|
|Agile changes||Yes.||Would require additional changes to distribute files. But one could still edit the config tree directly.|
|Publishing||What to publish? The ConfigFiles as well? Must you push new Jars? Could you publish the "active configuration"?|
- Unconference Session on ConfigByX, with good comments: Unconference 2014: ConfigByFile / ConfigByCode / Developer Sync Module
- Developers weigh in on the topic: http://forum.magnolia-cms.com/forum/thread.html?threadId=dacbff3f-0ce9-4293-b8b2-b5c1843568b7
- Configuration by Code: Original 5 arch notes & discussion: https://docs.google.com/document/d/13rqtHSlO9hp43ZMsjiGTPwViJBWbmlo3oERaz5lIdD8/edit#heading=h.8qo3tfbu4pb5
- Configuration by Code Concept: Configuration by code
- Readable bootstrap files. See: Config By X - File format discussions
- Configuration by File Concept: Concept - Config By File
- Frontend vision: Frontend vision
How can we ensure that edits via an AdminCentral app are not overwritten by ConfigByX at startup?
- Handle it like Inplace Templating: An extra property on the changed node, "preserve=true" prevents the ConfigByX from overwriting that node.
- ConfigByX is appllied first - then repository is applied on top of it.
- 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.