See: Concept - Config By X

Note, this concept is about the implementation of creating configuration via a file, whereas the format of the files is concepted here:Config By X - File format discussions

Purpose

Goals

Developers like working with files and have a lot of familiarity with tools and workflows there. It would be a benefit if configuration could be worked on the same as resources, templates and code.

In the ConfigByX document we explore the benefits of a "Volatile Configuration" over bootstraps that persist configuration to the repo. ConfigByFile is how non-java developers can take advantage of this. It also has the benefit of a clean hierarchical format.

Analysis

Why might some developers prefer to work on resources and templates as files (in an IDE or text editor) rather then in adminCentral? 

 AdminCentralIn files
 Easy to find
Everything in context 
Anyone can access and change running instance 

Multiple files at a time
Keyboard shortcuts 
Excellent and familiar UI of desktop IDE 

Requirements

  • Have a clean, human readable syntax (Not JCR “system view”) Maybe xml like "JCR document view", json, ...
    • The format has to come with a schema so we can e.g. offer autosuggest in editors
  • Configuration changes are considered without restart of the system

Implementation

  • Note: We'll have to implement BeanBuilders for the chosen format
    • Node2Bean might be reused to some extend
  • ...
  • No labels

7 Comments

  1. Magnolia International

    Config by code - not good for non-java dev ? Script it. DSL it.

    1. Christopher Zimmermann

      Can you please elaborate? What does "DSL it." mean?

      OK - Domain Specific Language - so create an api in a scripting language to assist developers know what is available?

      1. Magnolia International

        Make a DSL out of it

      2. Magnolia International

        Kinda, yeah. CBC implies a builder-ish, fluent-ish API. It should be doable to turn that into either a DSL, or at the very least, use Groovy to make it less java-ish (while keeping the tooling goodness)

  2. Magnolia International

    IMO:

    • files add configuration items, just like code and nodes do.
      • they're observed, and whatever observes them uses CBC to register whatever it is they're configuration
      • OR they actually are code (written in a DSL)
    • we need an additional view, not a replacement/extension of the config tree; we still need a jcr-view of the configuration workspace, and we can have specialized views, e.g. a template definitions viewer.
    • bootstrap files are still useful and necessary. They're the only way (AFAIK) to guarantee that a certain node has a given UUID. So they're the only way (again, AFAIK) for configuration to be activatable (which is sometimes desirable, sometimes not) - I'm not sure how you're seeing that publishing would still work in the table above.

  3. Cheng Hu

    Also may be desirable and/or ideal:

    • When working with config files in an IDE, content assist will work, for example in suggesting names for new nodes/properties
    • The tree created from the file can be editable in the Configuration App, and the changes will be saved to the file

  4. Cheng Hu

    Another thing that may be important to consider for Config by File is the tooling that will define a user's editing experience with the file format. For example:

    • Does YAML have an widely available editor in all platforms that supports automatic indentation using white spaces and collapsible sections?
    • Does JSON have a diff tool that recognizes JSON syntax and supports merge?