Skip to content

blueprints & inheritance: consider YAML builtins? #23

@drzraf

Description

@drzraf

The concept of blueprints expressed in the documentation seems very related to YAML inheritance, and most of BlueprintForm.php intents are related to this.

The form-plugin -> grav built-in blueprints -> toolbox form blueprints loading/importing, the closure magics and sparse documentation (aside from some phpdoc of little help) makes this part of the codebase huge, complex and really hard to understand.

I'm new to Grav codebase but I wonder whether YAML builtins would be a better fit

## pages/01.home/form.md
## Over-exagerated example
!include blueprint://my-form as my_form   # using an alias notation
!include plugin://foo/common-rules.yml    # or importing in a namespace derived from path
rules:
  <<: *my_form.rules
  <<: *plugins.foo.common_rules
form: *my_form.form
## plugins/foo/common-rules.yml
common_rules:
  blah: foo

If the main goal is to provide an easy YAML inheritance system, YAML already provides:

  • &anchor
  • *reference
  • <<: *merge
  • <<: *merge{partial: key}
  • and the ability to preprocess custom tags, eg an !include macro directive

These provides a much more explicit and flexible way to define inheritance relationships inside YAML.

Some examples of YAML preprocessors:

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions