Allow to inject dependencies into validation constraints

Well, we still use the default factory here:

class ConstraintManager extends DefaultPluginManager {

  /**
   * Overrides \Drupal\Component\Plugin\PluginManagerBase::__construct().
   *
   * @param \Traversable $namespaces
   *   An object that implements \Traversable which contains the root paths
   *   keyed by the corresponding namespace to look for plugin implementations.
   * @param \Drupal\Core\Cache\CacheBackendInterface $cache_backend
   *   Cache backend instance to use.
   * @param \Drupal\Core\Language\LanguageManager $language_manager
   *   The language manager.
   * @param \Drupal\Core\Extension\ModuleHandlerInterface $module_handler
   *   The module handler to invoke the alter hook with.
   */
  public function __construct(\Traversable $namespaces, CacheBackendInterface $cache_backend, LanguageManager $language_manager, ModuleHandlerInterface $module_handler) {
    parent::__construct('Plugin/Validation/Constraint', $namespaces);
    $this->discovery = new StaticDiscoveryDecorator($this->discovery, array($this, 'registerDefinitions'));
    $this->alterInfo($module_handler, 'validation_constraint');
    $this->setCacheBackend($cache_backend, $language_manager, 'validation_constraint_plugins');
  }

  /**
   * Creates a validation constraint.
   *
   * @param string $name
   *   The name or plugin id of the constraint.
   * @param mixed $options
   *   The options to pass to the constraint class. Required and supported
   *   options depend on the constraint class.
   *
   * @return \Symfony\Component\Validator\Constraint
   *   A validation constraint plugin.
   */
  public function create($name, $options) {
    if (!is_array($options)) {
      // Plugins need an array as configuration, so make sure we have one.
      // The constraint classes support passing the options as part of the
      // 'value' key also.
      $options = array('value' => $options);
    }
    return $this->createInstance($name, $options);
  }

The described class is just for the symfony part of the constrains.

ConstraintsManager uses ContainerFactory, and not ConstraintValidationFactory (which belongs to Symfony), so dependency injection works.

If this doesn't answer your question, then I'm afraid I don't know what you mean.

Yes, constraint plugins can implement ContainerFactoryPluginInterface, but validators cannot.

See CommentNameConstraintValidator.

Also see #2403817: Feed entity validation misses form validation logic - the protected function feedStorage() over there demonstrates that ContainerFactoryPluginInterface doesn't work for the validators.

And an example/failing test

And a fix showing it working

And remove the comment that sent me here.

looks great

beta eval, issue update

+++ b/core/lib/Drupal/Core/Validation/ConstraintValidatorFactory.php
@@ -0,0 +1,42 @@
+      if (is_subclass_of($class_name, 'Drupal\Core\Plugin\ContainerFactoryPluginInterface')) {
+        $this->validators[$class_name] = $class_name::create(\Drupal::getContainer(), [], NULL, []);
+      }

Passing along the plugin configuration/ID and definition is pointless afaik. Why do you not just use the ClassResolver?

Adapted the code a bit.

Nice

meh.

Let's fix it.

let's do it

better :)

This looks good, however I'm unsure how people will know they can do it that way? Should we document it at the manager given #2195083: Add a dedicated @Constraint annotation class is not done yet.

random fails

2197029-17.patch no longer applies.

error: patch failed: core/modules/comment/src/Plugin/Validation/Constraint/CommentNameConstraintValidator.php:7
error: core/modules/comment/src/Plugin/Validation/Constraint/CommentNameConstraintValidator.php: patch does not apply

reroll

Straight reroll

I think being able to unit test validators cleanly reduces fragility and there is no disruption. Committed 5f7ec33 and pushed to 8.0.x. Thanks!

Thanks for adding the beta evaluation to the issue summary.