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.
This seems like it could cause problems if some modules are using standard bootstraps - and some modules use ConfigByFile and overwrite other modules.
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.
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.