Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Config By X means that configuration for magnolia can be provided by different means - no longer only by jcr as today. Independently from how it's actually provided these configurations will end up in memory.

 

The Model layer

 

The X's (configuration options)

Config by JCR

Config by Code

Config by File

 

Config By X basically consists of the model (interfaces + definition classes) as well as the various mechanisms to populate the module (from JCR via Node2Bean, by Code via builders or by file via a new mechanism).

This page is about the model layer

Things to stay

  • mechanism to load in memory config e.g. right when starting an app should be kept as is


Things to add/change

  • Model classes need to host the info where they where loaded from (file, jcr, code)
    • <to check>: has to be per property, no?
  • Not all definitions are interfaces right now - to be changed
  • We should check using an annotation based generation mechanism
    • 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

  • Today merge happens in jcr (extends, override) - this has to happen in memory now
  • All X's have to have the same notion of path
    • e.g. to be able to tell what "element" you're overriding
  • We have to introduce an abstract bean representation tobe used in the vaadin container
    • folder, content, properties (find some wording which is ideally independent from jcr notation)
    • what icon to use
    • class and origin
    • path
    • ...

 

Things we won't tackle NOW

  • Publication of in memory config
    • we only consider getting config in jcr, code or file from author to public..

 

Open Issues

  • is supporting typical module definitions enough or do we need to support any config?
  • places where we're relying on jcr today - can they stay or do the have to operate on memory now?
    • server configuration is in jcr only - ok to not introduce definitions for this right now and hence there'll not (yet) be the option to change server config by file or code?
    • registries (dialogs, apps, ...)

 

TO - BE - MOVED - TO - PROPER - PAGES

Config By File (missing) (to be moved to a dedicated subpage)

  • format to be defined
  • BeanBuilder for the chosen format
    • Node2Bean might be reused to some extend

Config App

  • will no longer be a content app - has to work on definitions
    • we need common interfaces there

...