This document relates to the "Lower the Entry Barrier" initiative, codenamed "Ramp".
Here I will go into more detail about some of the concepts. These will probably be broken into individual documents.
Concepts to cover:
- Template & Resource Loading Cascade
- Inplace editing of Templates & Resources: Access filesystem
- Config By File: Configuration & Bootstrap improvements
- Work with config more like templates & resources.
- JCR Document View or JSON. Autoloading. Autoexporting
- Maybe it works like code in that it creates a dynamic configuration every time - not a permanent change to the configuration tree.
- Better Javascript handling.
- ConfigTree improvements. Extends insight. Template Extender tool.
- Enable frontend developers to create apps & fields with templates.
References
http://wiki.magnolia-cms.com/download/attachments/42270723/stk-remarks-vpro.pdf
Template & Resource loading cascade & Filesystem loading
Templates & Resources (and any other file assets) should be treated equivalently where possible.
Current problems
- Resources in repo are used by default (While templates in classpath are used by default)
- Its hard to get Resources into the repo. (reinstall). Adding new resources must be easy.
- Developers prefer to work on resources in the file-system - they are using IDE's.
- Storing templates in modules requires a java development environment.
Proposal
In order to stay flexible and support different use cases - system should implement a "loading cascade": loading things in a specified way from a specified series of locations
By default, Templates/Resources should be loaded in the following order. Items loaded later override the previous ones. The order goes from least flexible to most flexible.
- Modules (classpath).
- Directory on the filesystem.
- Repository that have "override" box checked.
- A master configuration item causes all items from repository to override.
(Alternatively, perhaps the mechanism only loads templates/resources that are not yet defined, instead of overwriting as defined above, in which case the default order would be reversed.)
Filesystem loading
- System should watch all files in configured directory and when changed
- reload them in the system
- add them to the repository, reload them to the repository
Questions:
- How to handle theme images?
Config by File
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
- The format of the bootstrap file is "clean", BUT the bootstrapping behaves the same. Loaded once at install, version updates.
- The files are loaded every time magnolia starts, and the repository nodes are overwritten.
- The files are loaded at mag start and used for item definitions, but the repository is not written to or used at all.
- The files are loaded at mag start and used for item definitions, repo is not written to...
- and adminCentral ConfigTree shows a view of the files.
- Edits in adminCentral are saved to the files immediately.
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 I take some nodes out of the configfile. This causes a problem because changes made by the 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?
This seems like it could cause problems if some modules are using standard bootstraps - and some modules use ConfigByFile and overwrite other modules.
How would ConfigByFile work with MVH
When they overwrite other modules - I guess these changes would "stick" in the repository. - possibly overwriting changes from other modules?
What about this technique for other workspaces - like Contacts? When would you not want it to always re-apply?
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. | |
| 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 |
Notes:
What if nothing was stored in repository?: Not templates or resources?
Templates and resources do not get stored in repository.
Admincentral inplace editing - edits the files directly. (In exploded War)Modifications to config tree get written to config files from where they were loaded.
That does not work for JARS.
ConfigByFile - Autowrite to File on ConfigTree edits.
If writes to the configTree were automatically written back to the ConfigFile - that would solve problem of loosing changes made in adminCentral.
But how would the system know to which file to write?
And how would it know when to write if some configuration is defined by File, but some is loaded from Bootstraps?
Proposals for Consideration:
- Filename is written as a property to the root node of the configuration it represents. So on change, it can walk down the tree till it finds the filename (or flag).
- Unlike bootstraps, ConfigFiles always start at a specific level. There is a separate file for each app, each dialog, and the basic "config" node for a module. As this is set - its easy for the system to generate the filepath of the file and check if it exists.
- All files are scanned to find matching file.
Overview
Content Tools