This document relates to the so called "STK3" initiative, which has evolved more into "Lower the Entry Barrier" initiative.
Most of the documents are in Google Drive.
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
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 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 Keyboard shortcuts | |
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 change.
- AdminCentral exports 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
- 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:
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 | 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 |
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.
Overview
Content Tools