Support defining conditions

A gave this a thought and imo the most elegant solution would be working constraints that we use to validate on widget submission.

Let's try that on an example workflow:

1. When a user creates a new EB field he should be able to define validation criteria. This means that we would have to construct an interface where the user could chose from a list of available constraints and then define constraint parameters. We would have to pre-define which constraints are applicable, maybe by creating a wrapper plugin around constraints and use this plugin to define the previously mentioned configuration form too. This would be saved in this field configuration.
2. The field configuration part is done and the user goes to create a new entity, opens the EB widget and starts creating the 'child' entity
3. When finished submits the form. On form validate we check the configuration of the parent field (It would help a lot to have the parent form available) and run the constraints.
4. How exactly validation is done wold have to take into account what the widget is doing, so I presume this would have to be widget's responsibility

Initial stab at this: https://github.com/drupal-media/entity_browser/pull/117/files

Still needs:
- a way to specify conditions
- cleanup
- tests

One important thing that we discussed is how we send those conditions/requirements to the entity browser.

My suggestion was to use the same as the EntityAutocomplete element. Hash the settings, store them by that hash in key value then pass along the hash in the URL or so.

Finally found time to continue working on this. Only Upload widget uses this validation for now- views widget runs it's own validation thing.

Also, as the patch stands now, it would require other widgets to follow.

Here's a vanilla re-base on top of 8.x-1.x, no notes addressed and no manual testing yet.

Last patch was no good, no idea why.

So after (visually) reviewing the current code and reading up on Symfony Constraints, I understand that the reason we're adding a new plugin is that we need to mock the typical use of Core's field validation. It's a pretty cool concept! Just need to do cleanup work on comments and inject more dependencies into the validator plugins, then test that it's working.

Updated patch which addresses all notes from https://github.com/drupal-media/entity_browser/pull/117 except the note on WidgetValidationBase::setConfiguration "We need to call this function from the constructor and respect default configuration before setting.". Not sure what is required for that.

Moving into manual testing now.

Fixed fatals, cleaned up more code, and made the Cardinality and EntityType WidgetValidators actually work. I believe this is ready for some form of review.

Re-roll.

Another huge re-roll, with a lot of code removed now that we have a generic way to pass information down to the Entity Browser.

Hopefully fixed tests.

Existing tests pass, writing new test coverage now.

Added a new test for the entity_type validator, I think this should be enough coverage for this patch unless we want to test every validator we have individually.

1. +++ b/entity_browser.api.php
   @@ -62,5 +62,16 @@ function hook_entity_browser_field_widget_display_info_alter(&$field_displays) {
   + * @param $validation_plugins
   

   Needs a type hint.

2. +++ b/entity_browser.api.php
   @@ -62,5 +62,16 @@ function hook_entity_browser_field_widget_display_info_alter(&$field_displays) {
   +function hook_entity_browser_widget_validation_info_alter(&$validation_plugins) {
   

   Should be type hinted.

3. +++ b/src/DisplayInterface.php
   @@ -71,4 +73,23 @@ interface DisplayInterface extends PluginInspectionInterface, ConfigurablePlugin
   +   * Gets the selection storage.
   

   I think this should say "Gets the selection storage values." Otherwise it sounds like we're getting the actual storage handler.

4. +++ b/src/Plugin/EntityBrowser/WidgetValidation/Cardinality.php
   @@ -0,0 +1,45 @@
   +    $max = $options['cardinality'];
   

   IMHO this should be $options['maximum'], for clarity's sake.

5. +++ b/src/Plugin/EntityBrowser/WidgetValidation/Cardinality.php
   @@ -0,0 +1,45 @@
   +      $message = 'You can not select more than %max Entities.';
   

   s/Entities/entities

6. +++ b/src/Plugin/EntityBrowser/WidgetValidation/EntityType.php
   @@ -0,0 +1,22 @@
   + * Validates that each passed Entity validates
   

   This sentence doesn't seem complete :)

7. +++ b/src/WidgetBase.php
   @@ -60,7 +61,14 @@ abstract class WidgetBase extends PluginBase implements WidgetInterface, Contain
   +  private $validationManager;
   

   Should be protected.

8. +++ b/src/WidgetBase.php
   @@ -189,7 +203,45 @@ abstract class WidgetBase extends PluginBase implements WidgetInterface, Contain
   +    if (in_array('submit', $trigger['#array_parents'])) {
   

   This is quite dangerous, IMHO. It's entirely possible that someone will have an element parent named 'submit', and then things will blow up for them. Can we find a better way of determining whether validation should occur? How about #limit_validation_errors?

9. +++ b/src/WidgetBase.php
   @@ -189,7 +203,45 @@ abstract class WidgetBase extends PluginBase implements WidgetInterface, Contain
   +        if (!empty($violations)) {
   

   $violations is an object, so it will never be empty. This should be $violations->count() > 0.

10. +++ b/src/WidgetBase.php
    @@ -189,7 +203,45 @@ abstract class WidgetBase extends PluginBase implements WidgetInterface, Contain
    +      $widget_validator = $this->validationManager->createInstance($validator_id, []);
    

    I'm not sure we need the if check here -- won't the plugin manager throw PluginNotFoundException if the constraint does not exist?

11. +++ b/src/WidgetInterface.php
    @@ -79,13 +79,27 @@ interface WidgetInterface extends PluginInspectionInterface, ConfigurablePluginI
    +   * @return \Drupal\Core\Entity\ContentEntityInterface[]
    

    Shouldn't this be EntityInterface[]?

#27.1/#27.2 - It looks like core doesn't use type hints for hook_*_info_alter() implementations, I'm not sure why. I cleaned up the whole api.php file.
#27.3 - Done
#27.4 - We use "cardinality" in a number of locations (entity_browser.common.js, entity_browser_entity_form.module), and so do some dependent contrib modules. I would be open to changing this across the board in a new issue if we choose to also support cardinality minimums.
#27.5/#27.6/#27.7 - Done
#27.8/#27.9 - Nice catches, done
#27.10 - Since the WidgetValidationManager extends DefaultPluginManager, we get the benefits of FallbackPluginManagerInterface and this function will not throw exceptions if a fallback plugin is available. See \Drupal\Component\Plugin\PluginManagerBase::createInstance() for details.
#27.11 - Done

#29,1
I think I remember that I every plugin needs to implement it because entities must exist if we want to reference them. We need to load them or create them. I am not sure if we can create a default. See upload widget example in patch.

This should address all concerns in #29, implementing prepareEntities() for the View widget actually abstracted some logic out of the submit handler, which is good too.

The Views widget implements its own validate() method, so we need to make sure it also calls the validators. I'll manually test as well.

Alright, the Views widget now calls the normal WidgetBase validate() method. I manually verified that cardinality and entity_type work with the Views widget as well.