Updates to plugin_type_example module

I think these changes make a lot of sense. This patch gets a hearty +1 from me.

A lot of good changes. Some changes that add to complexity, but I think it's probably worth it.

Thanks!

Some things I found:

1. +++ b/plugin_type_example/plugin_type_example.module
   @@ -11,45 +11,60 @@
   + * our Drupal\plugin_type_example\SandwichInterface, and INSERT ANNOTATION CLASSNAME HERE
   

   Clearly we need to insert annotation classname here. -)

2. +++ b/plugin_type_example/src/Controller/PluginTypeExampleController.php
   @@ -75,18 +78,19 @@ class PluginTypeExampleController extends ControllerBase {
   +    // annotation on the plugin class: see \Drupal\plugin_type_example\Plugin\Sandwich\ExampleHamSandwich.
   

   The class name should be on the next line if it doesn't fit in 80 chars.

3. +++ b/plugin_type_example/src/Controller/PluginTypeExampleController.php
   @@ -75,18 +78,19 @@ class PluginTypeExampleController extends ControllerBase {
   +    //$ham_sandwich_plugin_definition = $this->sandwichManager->getDefinition('meatball_sandwich');
   

   Either this is commented code, which is bad, or it's example code which should be properly indented and have a @code/@endcode tag.

4. +++ b/plugin_type_example/src/Controller/PluginTypeExampleController.php
   @@ -103,21 +107,14 @@ class PluginTypeExampleController extends ControllerBase {
   +   * For more about how dependency injection works read https://www.drupal.org/node/2133171
   

   Wrap the URL, add a @see annotation as well.

5. +++ b/plugin_type_example/src/Plugin/Sandwich/ExampleMeatballSandwich.php
   @@ -2,16 +2,15 @@
   + * Plugin\Sandwich namespace, and provide a Sandwich annotation to be declared
   + *  as a plugin. This is defined in
     *
     * The following is the plugin annotation. This is parsed by Doctrine to make
   

   Indentation and an incomplete sentence.

6. +++ b/plugin_type_example/src/SandwichBase.php
   @@ -0,0 +1,49 @@
   + * We intentionally declare our base class as abstract, and skip the order()
   + * method required by \Drupal\plugin_type_example\SandwichInterface. This way
   + * even if they are using our base class, developers will always be required to
   + * define an order() method for their custom sandwich type.
   

   To require that the method be implemented by subclasses, we'd declare it abstract on the abstract base class.

   The way this is set up, it doesn't actually implement the interface it says it does, which breaks for the wrong reason.

   So add abstract public function order() with {@inheritdoc} in the docblock.

7. +++ b/plugin_type_example/src/SandwichInterface.php
   @@ -1,5 +1,24 @@
   + * @file
   + * Provides \Drupal\plugin_type_example\SandwichInterface.
   + *
   + * When defining a new plugin type you need to define an interface that all
   + * plugins of the new type will implement. This ensures that consumers of the
   

   We don't do @file for 'provides' any more. This docblock should comment on the interface declaration, not the file.

8. +++ b/plugin_type_example/src/SandwichInterface.php
   @@ -15,4 +34,19 @@ interface SandwichInterface {
   +  /**
   +   * @param array $extras
   +   *   An array of extra ingredients to include with this sandwich.
   +   *
   +   * @return mixed
   +   */
   +  public function order(array $extras);
   

   Document what this method does.

9. +++ b/plugin_type_example/src/SandwichPluginManager.php
   @@ -30,17 +36,19 @@ class SandwichPluginManager extends DefaultPluginManager {
        $plugin_interface = 'Drupal\plugin_type_example\SandwichInterface';
   ...
   +    $plugin_definition_annotation_name = 'Drupal\plugin_type_example\Annotation\Sandwich';
   

   Use ::class for these class names, rather than string literals.

In PHP 5.5+ you can do the following, and the output will be the fully-qualified class name:

<?php

use Drupal\plugin_type_example\SandwichInterface;

echo SandwichInterface::class;

This is better because it means you have a more useful error if the interface is removed or gets moved around. It also helps IDEs.

Thanks.

+++ b/STANDARDS.md
@@ -23,22 +20,19 @@ Contributors can also patch the `phpcs.xml.dist` file itself, in order to fix
-Use Composer to add Drupal's Coder project to your root Drupal project. Coder
-contains the PHP_CodeSniffer rules we need, and also requires `phpcs`.
+Generally: Use Composer to add Drupal's Coder project to your root
+Drupal project. Coder contains the PHP_CodeSniffer rules we need, and
+also requires `phpcs`.

Seems like out of scope changes... You might need to pull the repo again.

Here's a patch with some more cleanup for CS.

Also, I just noticed that meatball sandwiches are different on Sundays, so I added a test, which breaks. :-) There's no t() on the plugin class, so either we have to demonstrate injecting services to the plugin, or we have to not translate the string. I'm not sure if the plugin system will do the translation on the annotation values, the way we have it set up.

+++ b/plugin_type_example/src/Plugin/Sandwich/ExampleMeatballSandwich.php
@@ -29,6 +30,9 @@ use Drupal\plugin_type_example\SandwichBase;
+  use StringTranslationTrait;

That works because \Drupal works, but it's a bit of a pet peeve of mine... #2733703: [plan] Service traits should require IoC injection

However, it turns out we can use a proper IoC dependency injection pattern with plugin objects: https://www.drupal.org/node/2012118

So here's a version with IoC injection.

OK, since we're basically RTBCing each other.... I'll just commit and mark fixed. :-)

Add a new issue for follow-ups.

Thanks!