Because we want to mix/combine configuration from multiple sources, we need to assess the impact on the product, define an approach — a model — to support usage and visualization of config by code, by file.
Status: consensus on basic approach, will start a spike to uncover pitfalls
Proposal for next step: rank issues (e.g. must-haves vs. would-be-nice)
Statement
We support typical module "domain" definitions, such as apps, dialogs, reusing the already existing registry-provider pattern.
Resulting config is loaded in memory.
On the table
- Domain definitions
- define what domain definitions are (e.g. anything that has a definition VS. anything that can be configured under a module...)
- Coverage of "unmapped" config
- config nodes that are not bound to a definition
- Probably no silver-bullet but would be nice to have a general mechanism for that too
- e.g. filters, applauncher layout
- needs to provide individual entries + ordering
- Make observation manager file-aware
- java 7 can natively observe the file system
- http://docs.oracle.com/javase/7/docs/api/java/nio/file/Path.html#register(java.nio.file.WatchService,%20java.nio.file.WatchEvent.Kind%5B%5D,%20java.nio.file.WatchEvent.Modifier...)
- might state that file observation is java 7-only
- code-awareness? hot-redeploys?
- Bean representation
- We need an abstract representation for config beans
- folders, nodes, properties
- wording is ideally independent from JCR notation
- to be used in the Vaadin containers
- what icon to use
- folders, nodes, properties
- Hold origin info — where beans were loaded from (file, JCR, code)
- class and origin/path
- has to be per property, no?
- All X's need to have the same notion of id/path
- tell what "element" you're overriding?
- when using a n2b extends, only properties from the top-most definition are accounted for
- we don't need to combine definitions/interfaces as mixins
- We need an abstract representation for config beans
- Decoration
- Today merge/decoration can be done only from/to JCR (extends, override)
- Has to happen in memory now
- Places where we're relying on JCR today
- can they stay or do they have to operate on memory now?
- need an overview what these are
- server configuration is in JCR only — it's basically a one by instance thingy
- typical registries (dialogs, apps, ...) should be suited for any additional providers
Config by JCR
- Not all definitions are interfaces right now
- ideally to be changed
Config by Code
- Investigate what generation mechanism could/should be used (involve Architects/Greg)
- Clarify where to place generated classes
- check how to use definition impls e.g. in tests then (might not be around after a mvn clean)
- Use convention over configuration
Config by File
- File residence
- File loader should support both config files in jar and from filesystem
- needs good convention
- keep the config files close to the template scripts
- Format
- Jackson lib seems powerful, supports a whole range of formats (https://github.com/FasterXML/jackson)
Not on the table now
- Publication of in memory config
- we only consider getting config in jcr, code or file from author to public...
- We do not need to support just any config
- Showing the consolidated config won't be a JCR content app anymore
Overview
Content Tools
1 Comment
Magnolia International
I don't see a case for anything else than keeping track of where the "root" object "comes" from (the dialog definition, the template def, etc)
I tend to see this as part of the "object key" (which is currently a made up string with a made up format like <module>:</path/to/thing>, but should be typed and hold relevant info)