[MAGNOLIA-6165] Simple include mechanism for yaml config files Created: 14/Apr/15  Updated: 12/May/15  Resolved: 06/May/15

Status: Closed
Project: Magnolia
Component/s: configuration
Affects Version/s: None
Fix Version/s: 5.4

Type: New Feature Priority: Neutral
Reporter: Magnolia International Assignee: Magnolia International
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependency
is depended upon by MAGNOLIA-6194 Figure out if/how to support relative... Accepted
Template:
Acceptance criteria:
Empty
Date of First Response:

 Description   

Until we reach conclusions and good design on how we're going to handle "extends" in the long run for configuration, we can implement a simple include mechanism for yaml files:

  • the spec allows us to create custom "tags" (e.g !include foo/bar.yaml)
  • we can benefit from the work being done with MAGNOLIA-6128 et al such that includes could reside anywhere
  • included files wouldn't suffer from indentation issues like a pre-processor could cause (i.e the include is parsed into a map and added as a value to the map-under-parsing)
    • as a consequence, references&anchors won't be useable between a "main" file and its includes


 Comments   
Comment by Magnolia International [ 06/May/15 ]

Current implementation supports absolute paths only. See magnolia-configuration/src/test/resources/info/magnolia/config/source/yaml/samples/includes.yaml for examples.

Comment by Mikaël Geljić [ 07/May/15 ]

Feature works nicely on technical grounds, but one has to know about some caveats at the moment:

a. Includee has to be visible in the same LayeredOrigin instance as the includer

  • e.g. !include /my-module/generic/column/status.yaml doesn't match any origin's pathPattern and won't be includable

b. Assuming we put includee e.g. inside the apps directory:

  • First, ConfigurationSource will try (and fail) to register it
    • e.g. in the example above, a workbench column class doesn't match that of an AppDescriptor
    • little to no use case for including an app in another app
  • Nevertheless, the includee is available for inclusion:
    !include /my-module/apps/status.column.yaml will work.

That said, there's no real change to be considered in the include mechanism itself, but rather in Origins.
The idea is to decouple them from a fixed pathPattern, i.e. pass it in when visiting instead.
Then a. origins may become singletons, and b. the use case for generic reusable bits of yaml will be nicely covered.

Considering all of this, this is now reviewed.

Generated at Mon Feb 12 04:11:55 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.