You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

This is the entry point for the whole Config By X theme.

What does it mean

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

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
  • No labels