rockettheme / toolbox

RocketTheme\Toolbox package contains a set of reusable PHP interfaces, classes and traits.
MIT License
21 stars 16 forks source link

blueprints & inheritance: consider YAML builtins? #23

Closed drzraf closed 5 years ago

drzraf commented 5 years ago

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:

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

Some examples of YAML preprocessors:

mahagr commented 5 years ago

We are using Symfony YAML which supports only some features of the YAML specification. We do support the PECL parser, too, if installed, but nobody really uses it, so it's likely not being installed to the servers so we cannot really require people to install it.

If the parser you use supports it, you can use YAML specs in the files as much as you want, but as Grav/Gantry also generates YAML, those relationships will get lost if those files get saved. Using YAML built-in references also break caching as the changes on the incuded files would not be detected without cache clear.