[MAGNOLIA-6194] Figure out if/how to support relative paths in YamlReader for includes Created: 06/May/15  Updated: 13/Apr/17

Status: Accepted
Project: Magnolia
Component/s: configuration, yaml
Affects Version/s: None
Fix Version/s: None

Type: Story Priority: Neutral
Reporter: Magnolia International Assignee: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
dependency
depends upon MAGNOLIA-6165 Simple include mechanism for yaml con... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Date of First Response:
Epic Link: Config by file / code
Story Points: 13

 Description   

As a developer, in my /foo/bar/qux.yaml file, I want to be able to write !include blah.yaml instead of !include /foo/bar/blah.yaml (i.e when the file-to-be-included is in the same directory)

Additionally, I might to be able to do

  • !include what/ever.yaml # to include /foo/bar/what/ever.yaml from /foo/bar/qux.yaml
  • !include ../what/ever.yaml # to include a file higher in another directory and/or a parent
  • !include **/kawabunga.yaml # to include the first file called kawabunga.yaml anywhere under /foo/bar
  • !include /**/kawabunga.yaml # to include the first file called kawabunga.yaml anywhere under the root folder
  • etc.. etc..

The last 2 proposals might seem a bit over the top, but would be super useful to keep things concise (include */common.yaml). They are inspired by FreeMarker's include directive, but differ by using instead of {} (thus looking more like a "glob" pattern), and by being relative to the current directory and going down, rather than going up the hierarchy like FreeMarker does (again, being closer to unix shells and globs).

Of course this story could be split in 2 if this isn't considered useful or is harder to implement than I thought (I'm think Origin.traverse() with a good Predicate might do the trick)

Additionally, I'd like to mention this will probably imply changes/improvements on Origin/ResourcePath, and YamlReader will end up just being a client of the new feature (with tests validating the integration).



 Comments   
Comment by Michael Mühlebach [ 09/Mar/17 ]

Is this still needed? With all the other features around decorate and extends?

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