Page History
...
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
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.
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
Table of Contents |
---|
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".
- System loads files from the modules (classpath).
- System loads files from a directory (specified in config) on the filesystem
- These could override the module files.
- System loads files from repository that have "override" box checked.
- A master configuration item would cause all items from repository to override.
Possibly: developers should be able to configure how they work with templates and resources.
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. Should they go in the DAM? Probably not.
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 one a developer prefer to work on resources and templates as files (in an ide or nice text editor) rather then in adminCentral? Most of these things would apply to configuration as well.
On filesAdminCentral | In adminCentralfiles | ||
---|---|---|---|
Easy to find Everything in context | Multiple files Keyboard shortcuts | ||
Key points
- Files have clean Clean syntax (Not JCR “system view”)
Applied dynamically. Either:
Not saved to repository (Does config tree show file contents?)
Re-applied to repository every time.
Active loader - system loads files automatically on change.
- (xml like "document view", json, ...)
- Files are applied dynamically. - Maybe at system start and everytime a file change.
- AdminCentral exports this file format.Exports clean syntax
- 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.
Broad implications
you can’t overwrite configuration anymore - you always have to extend it.
no module version handlers.
Questions
- Are file changes saved to repository?
Proposals
- The format of the bootstrap file is "clean", BUT the bootstrapping behaves the same. Loaded once at install, version update.
- 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:Suggestion
Any config in a file is loaded to repository at mag startup - completely overwriting the root node of the file and all children.
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 (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 | Possible | ||||
Agile changes | |||||
Yes. | ???? I guess you could create a file that overwrites the changes from other files. This seems comp | ||||
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 | no | yes | |||
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 | Deployment |