You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

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

Purpose

1. It can be convenient to work on things in admincentral - but it’s an inherent anti-pattern that changes made in adminCentral are not in your “project”. 

It causes additional headaches & work:

  • You must make the same changes in your files (resources&templates). You might forget.

  • You must export changes to configuration to bootstraps. You might forget.

  • You must import bootstraps or reinstall modules. You might forget.

  • You must write module version handlers to handle the configuration changes on update.

  • How can a team work together, and deal with version control on a "shared" configuration?

2. Also the workflow for configuration is completely different then that for code, which slows down productivity.

3. Many developer are very efficient at working in their IDE - faster then in AdminCentral.

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 DTD's etc.
    • Hierarchy is clearly visible as in treeview.

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: ConfigByFile or ConfigByCode 
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"? 

Alternative Approaches and benefits

  1. Volatile Configuration: The ConfigByX are loaded at startup and used for item definitions, but the repository is not written to.
    1. PRO: Whether I make changes to the bootstraps, or to the ConfigByX - it does not matter, the proper config is built when I startup.
       
  2. Writes to Repository: The ConfigByX are loaded at startup, and the repository nodes are overwritten with them.
    1. PRO: The JCR is still the single source of truth - and the only thing that needs to be activated.
    2. CON: Scenario: I have a configFile the writes to repo at startup, then I remove some nodes in the configFile - on next startup those deleted nodes would still be in the repo - dont see how system could understand to delete those nodes.

We plan on approach 1. All further comments are based on that plan.

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. Or, all manual changes are actually written to yet another repository: "manualconfig".
    • 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.

Resources 

Proposal

TBD

Implementation

TBD

Etcetera

How would we migrate from Bootstraps to ConfigFiles?

  • Should all bootstraps be converted to ConfigFiles?
  • If they were - would there then be a difference between "load-once" vs "load-every-start" config files?
  • What rules do we use to distinguish between things that should be "load-once" vs "load-every-start"?
  • Or should ALL configuration be loaded every start? (And manual changes / customizations are a layer on top of that.)

Considering "Writes to Repository" approach

A way that we could combine "volatile configuration" with having all active configuration in the repository - so that it could be published from there. Bootstraps & MVH write to the "stored configuration", the repository as we know it now. On each startup, the "stored configuration" is copied to a new "active configuration" in the repository - and all of the ConfigByX are applied to it. This ensures that changes in ConfigFiles are never persisted.. they are totally volatile.

  • No labels