Symfony's Config component allows for loading "resources" in flexible ways (from YAML, XML, PHP, annotations, and room to plug in more). Despite a name overlap, this is different than Drupal's Config component. Drupal's Config component is about dealing with user-editable configuration, whereas Symfony's Config component is for allowing code "wiring" to be managed. One example is routing (see #12). Another can be DIC registrations (which we currently do with PHP *Bundle classes, but could conceivably move to YAML). Very likely, more use cases will pop up.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

RobLoach’s picture

Title: Include the symfony config component » Add Symfony/Component/Config
Component: other » wscci
Status: Active » Needs review
Issue tags: +Dependency Injection (DI)
FileSize
203 KB

This would really help the Container as we could dynamically compile Container data from files, and potentially save configurations for later to improve performance. This is unrelated from the Drupal CMI, but it will help it.

Downloaded via drush composer create-project symfony/config.

Status: Needs review » Needs work

The last submitted patch, 1632930.patch, failed testing.

RobLoach’s picture

Status: Needs work » Needs review
FileSize
214.74 KB

Does format-patch do it?

Status: Needs review » Needs work

The last submitted patch, 1632930.patch, failed testing.

RobLoach’s picture

Status: Needs work » Needs review
FileSize
1.13 MB

--binary?

Status: Needs review » Needs work

The last submitted patch, 1632930.patch, failed testing.

RobLoach’s picture

Status: Needs work » Needs review
FileSize
1.13 MB

Interesting....

RobLoach’s picture

Status: Needs review » Needs work

Wrong patch.

RobLoach’s picture

Status: Needs work » Needs review
FileSize
214.71 KB

This one?

aspilicious’s picture

RobLoach’s picture

Status: Needs review » Closed (won't fix)

Would need to add via Composer anyway :-) .

effulgentsia’s picture

Title: Add Symfony/Component/Config » Add Symfony/Component/Config despite Symfony potentially releasing BC-breaking updates after 2.3.
Component: wscci » routing system
Status: Closed (won't fix) » Needs review
Issue tags: -Dependency Injection (DI)
FileSize
257.05 KB

Resurfacing this based on some work done in #1801570: DX: Replace hook_route_info() with YAML files and RouteBuildEvent. In that issue, we're reading in non-CMI YAML files (i.e., module-specified, not user configurable) for routes with just a few lines of custom code more or less like this:

$routes = Yaml::parse($file);
if (!empty($routes)) {
  foreach ($routes as $name => $route_info) {
     $requirements = isset($route_info['requirements']) ? $route_info['requirements'] : array();
     $route = new Route($route_info['pattern'], $route_info['defaults'], $requirements);
     $collection->add($name, $route);
  }
}

However, it would be nice to replace that custom code with:

use Symfony\Component\Routing\Loader\YamlFileLoader;
$loader = new YamlFileLoader();
$collection = $loader->load($file);

One benefit of doing so would be that that loader class supports a 'resource' key in the YAML file whose value can be some other kind of resource (either another YAML file, or a directory in which to look for controller annotations, or whatever other crazy thing people come up with).

However, all these loaders extend base classes and implement interfaces that are defined in Symfony's Config component.

Routing might not be the only use case along these lines. Anywhere we want modules registering declarative information that is not user-configurable could similarly benefit from Symfony's Config classes.

However, as with #1810472-11: Add Symfony's Serializer component to core despite Symfony potentially releasing BC-breaking updates after 2.3., this component is on fabpot's "strict BC is not guaranteed" list.

effulgentsia’s picture

Issue summary: View changes

fixed text

sun’s picture

I considered this thrice already, but I reviewed the sf Config component's code and it is simply too much.

This adds 250+ KB of yaml-to-array-to-treebuilder-to-typeddata-to-validation insanity to Drupal core that, realistically, can only be slow as hell. Please have a look into the deeper directories of the sf Config component. I have absolutely no idea why sf folks decided to make that a single component, given that they have overly abstract things like Validator already, and a seemingly too similar DomCrawler.

Iterating over array keys and loading resources takes much less than 10% of this component. No need to even remotely introduce a chance for invoking that insane treebuilder stuff.

If we wanted to use that tree stuff, then we need a really good concept first. A concept that outweighs the performance impacts. Hardly possible, but possible.

-1, please not. I'll definitely change my perspective if sf's Config component happens to be cleaned up.

effulgentsia’s picture

I don't see us wanting to use sf Config for anything that we don't cache (with very infrequent rebuilds) anyway. We cache routes in the {router} table. We compile/cache the DIC in php_storage. Etc. However, excessively long menu rebuilds on module enable are occasionally annoying, so the performance concern isn't entirely negligible.

dawehner’s picture

Version: 8.x-dev » 9.x-dev

Seems to be d9 material.

dawehner’s picture

Issue summary: View changes

Updated issue summary.

catch’s picture

Issue summary: View changes
Status: Needs review » Postponed (maintainer needs more info)
Issue tags: +Needs issue summary update
dawehner’s picture

Status: Postponed (maintainer needs more info) » Closed (won't fix)

Yeah I doubt we will go with that component in the future

Version: 9.x-dev » 9.0.x-dev

The 9.0.x branch will open for development soon, and the placeholder 9.x branch should no longer be used. Only issues that require a new major version should be filed against 9.0.x (for example, removing deprecated code or updating dependency major versions). New developments and disruptive changes that are allowed in a minor version should be filed against 8.9.x, and significant new features will be moved to 9.1.x at committer discretion. For more information see the Allowed changes during the Drupal 8 and 9 release cycles and the Drupal 9.0.0 release plan.