Page History
...
- maybe things should actually not be loaded to repository. This means you cannot do a clean uninstall.
- Should templates and resources really be loaded to separate locations in separate workspaces? What is the advantage of having these things scattered, instead of together?
Config by File
Meta: Break this topic into independent sub-topics:
- Readable bootstrap files.
- Config By File - No writing to repository
- Config By File - Writing to repository
What if configuration for templates and dialogs could be done in a file instead of in the adminCentral configuration tree?
This comes out of thinking of ways to treat resources and templates more equivelently, ie in a standard way. And then realizing that developers like working with files and have a lot of familiarity with tools and workflows there.
Why does a developer prefer to work on resources and templates as files (in an ide or nice text editor) rather then in adminCentral?
AdminCentral | In files | |
---|---|---|
Easy to find Everything in context | Multiple files at a time | |
Key points
- Files have clean syntax (Not JCR “system view”) (xml like "document view", json, ...)
- Files are applied dynamically. - Maybe at system start and everytime a file changes.
- AdminCentral can export this file format.
- Working on configtree in AdminCentral, Either:
- Auto export config files on change.
- You are seeing what is in files - and your edits are immediately written to the files.
Proposals for Consideration
...
...
Expanding on Proposal 2:
Any config in a file is loaded to repository at mag startup - completely overwriting the root node of the file and all children.
We need to ensure that these are loaded in a consistant, predictable order - as parts of files could be overwriting each other.
Potential problems:
Deleting a file.
Because they are loaded everytime - whatever is in the file is in the configuration. But if one deletes a file - that configuration probably stays the same. Unless we build a mechanism that if a configfile does not exist for a node, it automatically deletes. But that strategy assumes everything is configured by file, which is unlikely.
What if I change a node in the configTree. Will this get overwritten the next time I change the file?
Yes. Could we handle this like the templates? An extra property on a node "preserve=true", that prevents the ConfigByFile from overwriting that node.
Alternatively, if writes to the configTree were automatically written back to the ConfigFile - that would solve that.
How will this interact with bootstrap loaded configurations?
ConfigFiles are loaded every start, so when we change file - we know the repository will be in proper state. But bootstraps are only loaded once.
- What if Bootstrap & Configfile define the same node?
- Bootstrap is applied first, Configfile overwrites.
- So what if I have a bootstrap - then I add a config file, but then later I take some nodes out of the configfile. This causes a problem because changes made by the original config file are now persisted in the repo - even though we want and expect them to be dynamic
- If I re-install the module, the bootstraps run again - so that would fix that problem.
- Possible solution: Bootstraps & MVH write to the "stored configuration". ON startup, "stored configuration" is copied to "active configuration" and all of the ConfigFiles are applied to it. This ensures that changes in ConfigFiles are never persisted.. they are totally volatile.
- Problem with this is manual changes in adminCentral ConfigTree. How can they then be persisted?
- What if all manual changes were actually written to yet another level: "manual configuration"? Maybe manual configuration is just written to another ConfigFile which is always applied last. This would solve the overwrite problem - and it would be easier to see what manual changes should be merged back to files in source control.
- A variation is that many different "manual configuration" files would be written - cooresponding to the same ConfigFile structure - or at the very least one "manual configuration" file per module.
- Problem with this is manual changes in adminCentral ConfigTree. How can they then be persisted?
How do people override things specified in module ConfigFiles?
- Do they still use MVH?
- I think they just write their own ConfigFile fragments
How would ConfigByFile work with MVH that people have written?
- I guess it continues to work the same.
Analyzing implications of ConfigByFile
Implications | Config in AdminCentral | Config by File (Config by Code is similar) | |
---|---|---|---|
UI | See the entire running configuration. | Have multiple files (views) open. | |
Instant updates | Change the config from 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. | ???? I guess you could create a file that overwrites the changes from other files. This seems complicated. | |
Agile changes | Yes. | Would require additional changes to distribute files. But one could still edit the config tree directly. | |
Deployment | |||
Publishing | Would work. |
ConfigByFile vs ConfigByCode
byCode | byFile | ||
---|---|---|---|
See changes in config tree | could do | could do | |
Benefit of code completion | yes | no (Could theoretically have something like that with an xml file with a dtd.) | |
Easily see hierarchy | no | yes | |
Good for non-java dev. | no | yes | |
Possible to export from configTree | could do | yes |
Thought experiment: what if all bootstraps were installed everytime you restarted admin central?
So you would treat hand edits to the configtree as only experimental and temporary - like using firebug or browser dev-tools. You would know you have to "persist them" officially somehow. Hotfixes no longer possible.
Additionally - imagine that anytime the bootrap was changed it is reloaded. (problem with ordering, what if two bootraps write the same node, 2nd one overwrites. Then you edit the 1st file. Now repo is incorrect.)
So you could do your "hotfixes" by editing the files themselves.
Maybe a solution could be that if you edit in adminCentral - your changes are saved to a "manual change" layer - which is actually stored in another repository or file. This can be viewed independently and is therefore easy to re-integrate.
Thought experiment: could the repository know from which file all config comes from? What if whenever a bootstrap is loaded, an additional propertly is written to the root node in the config tree - the filepath of the bootstrap. So from any node you can walk up the tree to determine which bootstrap actually wrote that value. This would kind of be like "source maps" in web resources. What about MVH, would they also write a note to root of every node they change? Or would this eliminate need for MVH?
Editing files vs Editing Configuration - the two seem antagonistic.
Inplace editing of Templates & Resources: Access filesystem
...