Allow the AnnotatedClassDiscovery to use custom locations [#1831154]

While working on #1696648: [META] Untie content entity validation from form validation we needed a place to store our own plugins, but since this isn't a module and we didn't want to store everything inside system, we changed the AnnotatedClassDiscovery so it allows you to specify custom locations to search for.

Attached patch is a proof of concept, and if you want to test it, clear your cache after applying the patch.

How to use inside your own PluginManager

    $this->discovery = new AnnotatedClassDiscovery('Validation', 'Constraint');
    $this->discovery->custom_location = array(
      'Drupal\Core\Validation\Constraint' => array(array(
        'dir' => drupal_realpath('core/lib/Drupal/Core/Validation/Constraint'),
        'class_base' => 'Drupal\Core\Validation\Constraint',
      )),
    );
    $this->factory = new ConstraintFactory($this->discovery);

Comment	File	Size	Author
#8	extended-discovery-7.patch	3.64 KB	attiks
#8
#7	extended-discovery-7.patch	1.16 KB	attiks
#7
#3	extended-discovery-3.patch	3.67 KB	attiks
#3
	extended-discovery.patch	3.9 KB	attiks

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

tim.plunkett

he/him

English

Philadelphia

CreditAttribution: tim.plunkett commented 3 November 2012 at 19:55

Non-modules can already provide plugins.

For example, #1043198: Convert view modes to ConfigEntity adds Drupal\Core\Plugin\Core\Entity\EntityViewMode.

I think this would introduce confusion and uncertainty if Plugins could be *anywhere*.

Comment #2

fago

German

Vienna

CreditAttribution: fago commented 3 November 2012 at 20:03

But then all plugins what reside below the plugin system - what does not make any sense. It's not the plugin system providing those plugins. For example, we currently have typed data plugins reciding below the typed data system (based upon hook discovery). It are basic implementations provided by the typed data system, so they belong below \Core\TypedData.

Comment #3

attiks CreditAttribution: attiks commented 3 November 2012 at 21:22

File	Size
extended-discovery-3.patch	3.67 KB

New patch using get/set

Comment #4

3 November 2012 at 21:55

Status:

Needs review

» Needs work

The last submitted patch, extended-discovery-3.patch, failed testing.

Comment #5

tstoeckler

he/him

German

Essen, Germany

CreditAttribution: tstoeckler commented 4 November 2012 at 02:58

Re #2: I opened #1828616: AnnotatedClassDiscovery is not finding plugins in Drupal\(Core|Component)\COMPONENT_NAME\Plugin directory exactly because of that weird feeling I got dropping an entity type in \Drupal\Core\Plugin. :-)

Comment #6

attiks CreditAttribution: attiks commented 4 November 2012 at 04:43

For reference, fails on Fatal error: Class name must be a valid object or a string in /core/includes/entity.inc on line 265

Comment #7

attiks CreditAttribution: attiks commented 4 November 2012 at 05:14

Status:

Needs work

» Needs review

File	Size
extended-discovery-7.patch	1.16 KB

Comment #8

attiks CreditAttribution: attiks commented 4 November 2012 at 05:24

File	Size
extended-discovery-7.patch	3.64 KB

Comment #9

yched CreditAttribution: yched commented 4 November 2012 at 14:28

Currently it's easy to see what plugin implementations a module provides, you just look in its lib/[module]/Plugin folder, and easily see which plugins it provides, for which plugin types (say, a field widget, two field formatters, and a view row handler).

Big -1 to losing this if plugin implementations can be "anywhere". Making machine discovery more flexible shouldn't happen at the detriment of easy human discovery.

Comment #10

attiks CreditAttribution: attiks commented 4 November 2012 at 16:18

This isn't for modules but for core components, see #2

Comment #11

attiks CreditAttribution: attiks commented 4 November 2012 at 18:21

The longer answers after a cup of coffee

The idea is that we provide the same experience for non-modules, in the case of TypedData the plugins will be located inside core\lib\Drupal\Core\TypedData so they are easy to find.

You're right that a module in theory could use this mechanism to specify a different location, but I assume module builders will use the default.

Comment #12

tstoeckler

he/him

German

Essen, Germany

CreditAttribution: tstoeckler commented 4 November 2012 at 20:44

I agree with the criticism mentioned here. Maybe we can find a better solution in #1828616: AnnotatedClassDiscovery is not finding plugins in Drupal\(Core|Component)\COMPONENT_NAME\Plugin directory?!

Comment #13

attiks CreditAttribution: attiks commented 4 November 2012 at 20:58

Assigned:

attiks

» Unassigned

I would love to hear alternatives, the problem is not only about the names, but about the discovery process as well. The only problems is that people are now working around this limitation by either using a different discovery process or by putting their plugins inside core/modules/system or inside /Core/Plugin.

Comment #14

attiks CreditAttribution: attiks commented 9 November 2012 at 07:42

Comment #15

neclimdul

He/Him

CreditAttribution: neclimdul commented 10 November 2012 at 16:49

Status:

Needs review

» Closed (won't fix)

I agree with this not being a great idea for the points given. The problem itself also seems mistaken as if its not a module, it should be in the core class structure. This is already supported. The link tstoeckler posted is relevant for how that happens but since it is already possible I'm going to close this.

Comment #16

attiks CreditAttribution: attiks commented 10 November 2012 at 17:30

Status:

Closed (won't fix)

» Active

So where are we supposed to put them, my code lives inside core\lib\Drupal\Core\Validation\Constraint, so do I put my plugins inside core\lib\Drupal\Core\Plugin? Or somewhere else?

I don't mind you closing the issue, but at least give us some feedback on how to handle it