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.
Comment | File | Size | Author |
---|---|---|---|
#12 | symfony-config.patch | 257.05 KB | effulgentsia |
#9 | config.patch | 214.71 KB | RobLoach |
#7 | 1632930_2.patch | 1.13 MB | RobLoach |
#5 | 1632930.patch | 1.13 MB | RobLoach |
#3 | 1632930.patch | 214.74 KB | RobLoach |
Comments
Comment #1
RobLoachThis 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
.Comment #3
RobLoachDoes format-patch do it?
Comment #5
RobLoach--binary?
Comment #7
RobLoachInteresting....
Comment #8
RobLoachWrong patch.
Comment #9
RobLoachThis one?
Comment #10
aspilicious CreditAttribution: aspilicious commentedChances are we dont need it after all... #1599108: Allow modules to register services and subscriber services (events)
Comment #11
RobLoachWould need to add via Composer anyway :-) .
Comment #12
effulgentsia CreditAttribution: effulgentsia commentedResurfacing 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:
However, it would be nice to replace that custom code with:
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.
Comment #12.0
effulgentsia CreditAttribution: effulgentsia commentedfixed text
Comment #13
sunI 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.
Comment #14
effulgentsia CreditAttribution: effulgentsia commentedI 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.
Comment #15
dawehnerSeems to be d9 material.
Comment #15.0
dawehnerUpdated issue summary.
Comment #16
catchComment #17
dawehnerYeah I doubt we will go with that component in the future