Entity behaviors, bundle behaviors, bundle options

#1:
Example:
You want a behavior that gives "karma" to a user every time he/she views a node.
You want this to be configurable per node type.

Later you want the same behavior to apply to commerce products.

Bundle behavior classes

First, you create a behavior class:

namespace Drupal\my_module\BundleBehavior;
class EntityViewKarmaCounter {

  protected $increment;

  function __construct($increment) {
    $this->increment= $increment;
  }

  /**
   * Subscriber method
   */
  function entityWasViewed($entity, $type, $bundle, $user) {
    $user->karma += $this->increment;
    .. // somehow save the new karma value
  }
}

This thing really knows nothing about where the $increment is configured, and why or how it is subscribed to those bundle events.
It does not need to think about "am I really enabled for this bundle?". Because if it wasn't, the subscriber method would not fire.

As if this wasn't good enough, you decide to add an alternative implementation, which has a different formula for the karma:

namespace Drupal\my_module\BundleBehavior;
class EntityViewKarmaCounterUnfair {
  function entityWasViewed($entity, $type, $bundle, $user) {
    // More important users get more karma per view. We like to be unfair!
    $user->karma += count($user->roles);
    .. // somehow save the new karma value.
  }
}

This behavior does not even have constructor arguments.

Bundle option code

Now, separate from the behavior classes, you create the option code.
I don't know yet whether this should be one class, or a collection of classes, or hooks, or whatever.

The important part is that it should happen outside of the behavior code.

The option code does this:

• Define a configuration form. This has
  - radios where you can choose one of the above karma formulas, or disable the karma counter.
  - a number field to define the increment.
  The configuration form elements will be displayed in the bundle configuration form, for entity types that have this option.
• Define how to store those options (per bundle).
  E.g. it tells the system that it wants to store two numbers per bundle: One for the radios, another for the karma increment.

namespace Drupal\my_module\BundleOption
class EntityViewKarmaCounter {

  protected $allowUnfairIncrement

  /**
   * @param boolean $allow_unfair_increment
   *   The unfair increment is only available on some entity types, not all.
   */
  function __construct($allow_unfair_increment) {
    $this->allowUnfairIncrement = $allow_unfair_increment;
  }

  /**
   * Callback method for form building
   */
  function buildFormElements(...) {
    ...
    if ($this->allowUnfairIncrement) {
      ... // add one more radio option
    }
  }

  function formSubmit(..) {
    ... // prepare for storage
  }

  /**
   * Callback method for storage definition
   */
  function getStorageDefinition() {
    ... // define that we need two integer slots.
  }
}

Entity behavior class

This class does the following:

• Tell the system about the option class you created.
• Based on the configuration for the bundle, it decides which behaviors it wants to attach.

namespace Drupal\my_module\EntityTypeBehavior;
class EntityViewKarmaCounter {

  protected $allowUnfairIncrement

  function __construct($allow_unfair_increment) {
    $this->allowUnfairIncrement = $allow_unfair_increment;
  }

  /**
   * Subscriber method, which allows to register bundle options.
   */  
  function registerBundleOptions($api) {
    $api->registerBundleOption(new Drupal\my_module\BundleOption\EntityViewKarmaCounter($this->allow_unfair_increment));
  }

  /**
   * Subscriber method which fires when a bundle ("entity subtype") is initialized in a request.
   * @param $bundle
   *   Object representing the bundle ("entity subtype"). 
   * @param $bundle_config
   *   Configuration for this bundle. Options coming from multiple "bundle option" components.
   */
  function initEntityBundle($bundle, $bundle_config) {
    switch ($bundle_config['karma_counter']['counter_type']) {
      case KARMA_COUNTER_FIXED_INCREMENT:
        $behavior = new Drupal\...\BundleBehavior\EntityViewKarmaCounter($bundle_config['karma_counter']['increment']);
        break;
      case KARMA_COUNTER_UNFAIR_INCREMENT:
        $behavior = new Drupal\...\EntityViewKarmaCounterUnfair();
        break;
      default:
        // Behavior is disabled.
    }
    $bundle->attachBundleBehavior($behavior);
  }
}

Note how this behavior class is agnostic about the entity type.

Register the entity behavior

Now you need to tell Drupal about the entity type behavior, and which entities it should be available for.

/**
 * Implements hook_entity_type_behaviors()
 */
function my_module_entity_type_behaviors($api, $entity_type) {
  switch ($entity_type) {
    case 'node':
    // For nodes, we allow the unfair option.
    $api->registerEntityTypeBehavior(new Drupal\...\EntityTypeBehavior\EntityViewKarmaCounter(TRUE));
    break;
  case 'commerce_product':
    // For products, we don't allow the unfair option.
    $api->registerEntityTypeBehavior(new Drupal\...\EntityTypeBehavior\EntityViewKarmaCounter(FALSE));
    break;
  }
}

Of course we may decide not to make this a hook, but something else. Too early to decide that.

Our custom module now has
- no hardcoded entity types outside of hook_entity_type_behaviors().
- no hardcoded bundle names anywhere.
- no complex logic to determine if something applies to a given bundle type.

I don't know if what we have today really covers what I was proposing in this issue.

But anyway, I think I rather open a new issue when I have a more concrete idea what I want, and a better way to explain it. I don't even want to read my own lengthy post anymore.