Page tree
Skip to end of metadata
Go to start of metadata

Motivation

  • Capture the advantages of Config by File
    • A developer can edit it in the IDE if that is more familiar
    • A developer can merge changes from other developers using merge tools
    • A developer does not have to import after merge
    • A developer does not have to export configuration changes to bootstrap files to persist them if editing using IDE
    • An admin can easily uninstall a module, and know for sure all its effects on config are gone
  • Allow users to still leverage the Configuration App to create and edit configuration
    • Magnolia specific autosuggest
    • Magnolia specific error highlighting
    • Magnolia specific help text
    • Visualize extends
    • Click reference to jump to it
    • ...etc.
  • Avoid adding the complexity of layers for users and programmers
    • Users should not have to think about layers unless it brings some great advantage
    • Programmers should not have to think about layers unless it brings some great advantage

Proposed Features

Configuration App saves and clearly displays what changes have been made by the user since a clean install

System remembers the state of configuration after clean install


User adds new nodes and properties that do not exist in a fresh install in the Configuration App


User deletes nodes and properties that exist in a fresh install in the Configuration App


User changes property values in the Configuration App


Reload Configuration action which rebuilds configuration tree from modules as if fresh install




 

Update Configuration action which rebuilds configuration tree from modules as if fresh install, then reapplies user changes




Other convenience actions

  • Show all user edits – Show all user edits in selected subtree by expanding the subtree
  • Delete all user edits – Delete all user edits in selected subtree
  • Export user edits / Import user edits – Export user edits in selected subtree to file / Import user edits to selected subtree by reading file created by export
  • Hide user deletes – Do not show items deleted by the user from the fresh-install configuration, can be a checkbox in the app header

Scenarios

Developer creates new configuration or configuration that modifies existing configuration by file

  1. Developer makes changes to configuration bootstrap files directly in the IDE
  2. Developer opens the Configuration App and executes Reload configuration or Update configuration, depending on whether they want to preserve user changes made in the Configuration App
  3. Changes made to the configuration bootstrap files directly in the IDE are now reflected in Magnolia

Notes

  • Configuration can be loaded from anywhere, including Git
  • Would be nice to have a tool to compare before and after reload configuration so developer can tell what has changed, and rollback if necessary

Developer creates new configuration or configuration that modifies existing configuration by UI

  1. Developer modifies configuration in Configuration App just as he/she does now
  2. Developer gets to benefit from all the editing aids in Configuration App such as autosuggest
  3. Developer can also clearly see what edits he/she has made by looking at the source column
  4. Developer exports the changes to configuration bootstrap files as they do now
  5. Developer can test whether the new bootstrap files are correct by executing Reload configuration, without having to delete and reboot the repository as they do now

Notes

  • Again, would be nice to have a tool to compare before and after reload configuration so developer can tell if the exported result is correct, and rollback if necessary

 

Developer merges changes from other developers by file

  1. Developer checks out changes to configuration bootstrap files from another developer and merges the files using a third party tool in the IDE
  2. Developer opens the Configuration App and executes Reload configuration or Update configuration, depending on whether they want to preserve user changes made in the Configuration App
  3. Changes made to the configuration bootstrap files as a result of the merge are now reflected in Magnolia

Notes

  • Again, would be nice to have a tool to compare before and after reload configuration so developer can tell what was changed as a result of the merge, and rollback if necessary

Administrator hot-fixes configuration on the author instance and publishes it

  1. Administrator makes and stages hot-fixes in the Configuration App on the author instance just as he/she does now
  2. Administrator publishes the change to the public instance just as he/she does now
  3. Administrator can clearly see what hot-fixes has been made to the clean-install configuration by looking at the source column

Administrator exports hot-fixes to communicate to developers

  1. Administrator exports user changes to the configuration tree to a file using the Export user edits action in the Configuration App
  2. Administrator gives export files to developers
  3. Developer use Import user edits to apply the changes in the Configuration App
  4. Developer can clearly see what user changes have been made by looking at the source column
  5. Developer exports the changes to configuration bootstrap files as they do now
  6. Developer can test whether the new bootstrap files are correct by executing Reload configuration, without having to delete and reboot the repository as they do now

Administrator upgrades existing module on author and public

  1. The interface for module upgrade is the same as it is now, with server restart, except in the background we run Update configuration to update the configuration while preserving user edits, rather than using MVHs as we do now
  2. Since the configuration is re-created from the configuration bootstrap files during upgrade, this means there is no more need to write MVH deltas
  3. This assumes the configuration created by running the MVH on top of a configuration tree that contains user changes  == the configuration created by doing a new installation using bootstrap files and then reapplying the user changes

Notes

  • Is it possible to upgrade a module without restarting the server using Update configuration?

Administrator installs new module on author and public

  1. The interface for module install is the same as it is now, with server restart, except in the background we run Update configuration to update the configuration while preserving user edits, rather than using MVHs as we do now

Notes

  • Is it possible to register a new module and install it without restarting the server using Update configuration?
  • Doing so would be highly compatible with the Java free module story and the module can be anywhere, even in git

Administrator uninstalls a module on author and public

  1. De-register the module, by for example removing the jar file as we do now
  2. During next startup, run Update configuration to update the configuration while preserving user edits
  3. Since the configuration is re-created only from the existing modules, changes to the configuration due to the uninstalled module are guaranteed to not exist
Notes
  • Is it possible to uninstall a module without restarting the server using Update configuration?

Developer creates new configuration or configuration that modifies existing configuration by code

TODO

Advantages

  • (tick)Capture the advantages of Config by File
    • (tick)A developer can edit it in the IDE if that is more familiar
    • (tick)A developer can merge changes from other developers using merge tools
    • (tick)A developer does not have to import after merge
    • (tick)A developer does not have to export configuration changes to bootstrap files to persist them if editing using IDE
    • (tick)An admin can easily uninstall a module, and know for sure all its effects on config are gone
  • (tick)Allow users to still leverage the Configuration App to create and edit configuration – users can still create and edit configuration in the Configuration App just as they do now
  • (tick)Avoid adding the complexity of layers for users and programmers
    • (tick)Users do not have to think about layers – Configuration App behaves exactly as it does not
    • (tick)Developers do not have to think about layers – programming model is exactly the same as now
  • Other potential advantages
    • Familiar and improved for people already familiar with Configuration App – can create configuration exactly the same way as they do today, but with greater ease
    • Probably easier to implement than layers – layers would require some form of reload anyway
    • Probably more backwards compatible than layers – the master configuration is still loaded in the JCR
    • Compatible with idea of Java free module that can be either a folder on the file system or anywhere (ex. on github)
    • Does not introduce new security and ACL issues
    • Supports JCR clustering which may be problematic with files

Disadvantages

  • If a developer is editing configuration by file, they will not be able to reload after every small edit because reload will likely be too slow for that. So if a developer is editing configuration by file, he/she must edit in batches and reload.
  • If an administrator wants to hot-fix by editing the configuration file rather than using the Config App, they will not be able to use reload to read in the changes if reload cannot guarantee 100% accuracy and is slow
    • However, for Config by X Using Layers, it is also not clear if an administrator can hotfix at all by editing the configuration file

Reference

  • No labels