* Create typed config object.
  protected function parseElement($key, $data, $definition) {
    return \Drupal::service('config.typed')->create($definition, $data, $key, $this);

   * Build data definition object for contained elements.
   * @return \Drupal\Core\TypedData\DataDefinitionInterface
  protected function buildDataDefinition($definition, $value, $key) {
    return  \Drupal::service('config.typed')->buildDataDefinition($definition, $value, $key, $this);

This means that only the container's version of the typed config manager can ever be used.

We should inject the typed config manager when the typed config manager creates instances. This is a refactor - test coverage of schema parsing and traversing is done for every single web and kernel test. Doing this makes #2414951: Validate configuration schema before importing configuration possible.

#1 2414953.1.patch2.86 KBalexpott
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 85,216 pass(es). View
Members fund testing for the Drupal project. Drupal Association Learn more


alexpott’s picture

Issue summary: View changes
Status: Active » Needs review
2.86 KB
PASSED: [[SimpleTest]]: [PHP 5.4 MySQL] 85,216 pass(es). View
Gábor Hojtsy’s picture

Status: Needs review » Reviewed & tested by the community

I looked at #2298687: Sequence and Mapping implement interfaces incorrectly, make them honest about what they support which is @tstoeckler/@reyero's ongoing refactoring of these classes. It moves those methods of Element to ArrayElement (and does away with Element entirely), because only arrays spawn new elements. I think this change will be possible to integrate in that patch and does not go against those efforts in any way. Also not sure this can be made better by moving towards that vision here because that would expose more of the refactoring here instead of the current goal of injecting the typed data manager.

So overall looks good to me as-is.

tstoeckler’s picture

Yup, great idea!

Jose Reyero’s picture

This makes a lot of sense.

The problem is it is one of the "features" inherited from TypedData and I think the place to fix all these dependencies is here, in the base TypedData class, several methods: getPluginDefinition(), getConstraints(), validate(), and still more in derived classes.

* This kind of 'hardcoded' typed data manager / typed data manager' is one of the reasons why we cannot really reuse too much from typed data classes.

catch’s picture

Status: Reviewed & tested by the community » Fixed

Committed/pushed to 8.0.x, thanks!

  • catch committed f6e336c on 8.0.x
    Issue #2414953 by alexpott: Element uses \Drupal::service() as a service...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.