I'm talking about some hooks like

- hook_config_info(), that could provide information about configuration files or bundles and be available at boot and also provide which class would handle each config.

- hook_variable_info(), that could provide information about specific variables on each file (name, type, etc) so we can also generate config forms on the fly.

The idea is implemented in variable module, it could be a good starting point, see http://drupal.org/project/variable

Comments

gdd’s picture

Issue tags: +Configuration system

tagging

sun’s picture

Title: Implementing metadata about configuration. » Meta data for configuration
Project: » Drupal core
Version: » 8.x-dev
Component: Code » configuration system
  1. As outlined in #1542578: Multilingual and translatable configuration, the conclusion of a config-related sprint in Denver was that it doesn't make sense to create something new and re-invent the wheel. Instead, the envisioned goal is to advance on the idea of #1346214: [meta] Unified Entity Field API, which wants to abstract the current Field API types + validation + widgets + formatters so they work identically for entity-level properties, and just take the small next step and turn it into a generic Property API. That Property API would then be used by Field API, Entity API, and the configuration system.
  2. Based on that, it should be easily possible to generate form elements for configuration object properties.

    (In turn, that might revert some parts of #1324618: Implement automated config saving for simple settings forms, in case we'll go with a short-term stop-gap solution in there.)

  3. hook_config_info(), that could provide information about configuration files or bundles and be available at boot and also provide which class would handle each config.
    • The configuration system must be able to work (long) before the module/hook system is initialized.
    • The configuration system also does not need and should not need to contain any knowledge about the meaning of configuration values. Meta data is only required for higher-level logic, such as a user interface for editing configuration.
    • I object to any idea that adds a dependency on the module/hook to all configuration.
    • I did, however, raise the idea of allowing a dependency on other subsystems for configuration objects that mainly work at a higher level in the application stack, such as image styles and vocabularies and whatever else previously lived in database tables. That's however a dependency on a completely different level: The configuration system can happily work without any other subsystem. Only certain configuration objects may depend on other subsystems to be fully functional. This idea is being discussed in #1609760: hook_image_style_*() is not invoked for image styles upon Image module installation.
  4. This issue does not seem to be related to the discussion of configuration realms/domains and contextual configuration overrides. I'd strongly suggest to create a new, separate issue for that topic.
Jose Reyero’s picture

Sorry, I forgot about this issue.

Working on a different metadata system for configuration here #1648930: Introduce configuration schema and use for translation

Jose Reyero’s picture

Status: Active » Closed (duplicate)