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.

Files: 
CommentFileSizeAuthor
#12 symfony-config.patch257.05 KBeffulgentsia
PASSED: [[SimpleTest]]: [MySQL] 46,219 pass(es).
[ View ]
#9 config.patch214.71 KBRobLoach
PASSED: [[SimpleTest]]: [MySQL] 37,024 pass(es).
[ View ]
#7 1632930_2.patch1.13 MBRobLoach
PASSED: [[SimpleTest]]: [MySQL] 36,846 pass(es).
[ View ]
#5 1632930.patch1.13 MBRobLoach
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in 1632930_1.patch.
[ View ]
#3 1632930.patch214.74 KBRobLoach
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in 1632930_0.patch.
[ View ]
#1 1632930.patch203 KBRobLoach
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in 1632930.patch.
[ View ]

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)
StatusFileSize
new203 KB
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in 1632930.patch.
[ View ]

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
StatusFileSize
new214.74 KB
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in 1632930_0.patch.
[ View ]

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
StatusFileSize
new1.13 MB
FAILED: [[SimpleTest]]: [MySQL] Invalid patch format in 1632930_1.patch.
[ View ]

--binary?

Status:Needs review» Needs work

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

RobLoach’s picture

Status:Needs work» Needs review
StatusFileSize
new1.13 MB
PASSED: [[SimpleTest]]: [MySQL] 36,846 pass(es).
[ View ]

Interesting....

RobLoach’s picture

Status:Needs review» Needs work

Wrong patch.

RobLoach’s picture

Status:Needs work» Needs review
StatusFileSize
new214.71 KB
PASSED: [[SimpleTest]]: [MySQL] 37,024 pass(es).
[ View ]

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)
StatusFileSize
new257.05 KB
PASSED: [[SimpleTest]]: [MySQL] 46,219 pass(es).
[ View ]

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