Page tree
Skip to end of metadata
Go to start of metadata

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: (star) 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
    • (question) 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
  • 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
    • Hold origin info — where beans were loaded from (file, JCR, code)
      • class and origin/path
      • (question) 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
  • 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)
  • (question) 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
    • (question) needs good convention
      • keep the config files close to the template scripts
  • Format

 

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

1 Comment

  1. host the info where they where loaded from (file, jcr, code): <to check>: has to be per property, no?

    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)