This is a page to collect a shared list of use cases for context-specific configuration in Sling-based applications, see discussion on mailing list.

From Stefan

A collection of use cases for what we need context-specific configuration per site, country, region etc. in our projects. According to the term definitions in Multitenancy scenarios and use cases we have always "Massive Multi Site" scenarios.

  • Separate Site URLs (external domain names) for HTTP, HTTPs and Author (HTTP and HTTPs often have different domain names due to CDN in front of the webservers)
  • Configure different styles of navigation layout depending on preference of the market
  • Tweak some frontend-settings for the site, e.g. include JavaScript/CSS snippts or external files like Psyma
  • Configure different webfonts to be used based on the markets language and charset
  • Configure regexp patterns for browsers in the market for that a "use a newer browser version" should be shown
  • Configure Search Integration with a Google Search Appliance or other external Search engines with an market-specific index which could contain CMS-external content as well
  • Configure a list of news or event categories for the site
  • Switch on/off social sharing integration like addthis.com and configure services to be shown
  • Configure user tracking
  • Configure links to external systems integrated centrally in the site
  • Configure Google Maps integration specific for the country
  • Choose between preconfigured SSO systems to activate for a specific site

In general no security-sensitive stuff is stored in the context-specific configuration. If this is needed they are stored in OSGi configurations and referenced from there (e.g. by a named factory configuration).

  • No labels

1 Comment

  1. Dominik Süß

    Ok here my additions as comment since I have no write permissions here:

     

    Configuration Reading vs Editing

    The following requirements partially also target the configuration editing and therefore corresponding constraints. This is to acknoledge the fact that a new API must not leak implementation details in a way that makes consumers rely on implementation details (especially persistence structures) while taking into account that there is a need to be able to write configuration back in various cases. The requirements are not driven by UI but should only reflect some logical constraints comming from the editing flow (such as preconditions for multistep wizards where steps build on data entered in previous steps).

    Requirements (collected from two implementations dealing with configurations mostly for integrations)

    • For some cases of backend integration it is necessary to store credentials for server to server access in conjunction with configuration that needs to be consumed for rendering. When retrieving the configuration with the context of an enduser there must be a way to secure the sensitive credentials  so they get not unveiled through the consumer (pure reading of configuration)
    • For the case of 1:n integrations it is necessary to have n configurationobjects of the same type that can be consumed by some factory service.
      • e.g. A backendconfiguration exporting different sets of data to the same end systems, so sharing the logic but containing different mappings and probably even different credentials for the endsystem.
    • For some cases of backend integration it must be possible to look up a configuration by some service without a real user (Configuration lookup by services)
      • e.g. when a service is exporting data in some interval based on some configured mapping
    • (minor) It would desirable to be able to look up consumers of a configuration for maintainability (currently possible for custom solution since linking configurationcontainer is done by a path reference stored in a resource that inherits this to descendants)
      • This probably does not have effect on the API but probably on best practices how a consumer can declare and persist that he is consumer so that a lookup of the current consumers can be done by some generic logic e.g. from within the configuration editor. In case of a CMS it would answer a question like: Which sites are bound to this configuration container?
    • (Editing) For some cases of backend integration it must be possible to update configuration programmatically through some service without a real user (Configuration Sync initiated by 3rd Party service)
      • e.g. configuration of a backend service might just be performed asynchronous taking minutes so returned mapping must be written back by some callback service
    • (Editing) For some cases of backend integration it is necessary to store credentials for the configuration to establish the server-to-server communication that must not be unveiled to the user doing some consumerconfiguration (editing configuration based data retrieved from a 3rd source)
      • This is a variation of the first requirement just making clear that there are even cases where the editor of a configuration must not be capable of reading all properties.
    • (Editing) For some cases of backend integration it is necessary to register a multi-step configuration flow (wizard) looking up and validating data step by step based on custom logic (configuration wizard consuming and validating values against custom logic or 3rd party systems)
      • e.g. A backendconfiguration where credentials have to be entered first, then the available endpoints within the target system can be retrieved and then a mapping can be performed. 
      • Note: this potentially could be potentially completely up the the configuration editor and not be an API constraint but the implementation shoult take into account that in case of intermediate saves it might be necessary to even save incomplete configuration
    • (Editing - minor) It would be desirable to be capable to unify interfaces dealing with the configuration and data produced by this integration
      • e.g. having an interface that allows configuration of the integration and showing statistics about the usage of the integration in one location (probably indicating (optional) separation of editorinterface location and actual storage of configuration)
    • For some cases of integrations it would be desirable to pick a container aggregating a coherent set of configurations and bind it to a branch of the resouce tree
      • e.g. a set of integrations that rely on each other so that binding the single integration configurations would be error prone.
    • For some cases of configuration it might be necessary to nest configurations building a rich configuration structure
      • e.g. configuring the interface and storage composition of some tools available in the system
    • For some cases of configuration there should be a way to constraint the amount of configurations of a specific type available in a specific container
      • e.g. defining that a specific backend can only be created once making lookup unambiguous