Use contexts as payment bundles.

Postponed until 7.x-2.x

CommentFileSizeAuthor
#13 payment_1896416_13.patch16.22 KBxano
#12 payment_1896416_12.patch15.25 KBxano

Comments

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented

We may want to rename contexts to "payment types", and create different classes for the different types. A payment that is of the base class is a payment without a type. We can let payment types be exposed plugin classes, and use a custom payment entity storage controller to decide which entity class to use. We can use the plugins' machine names as bundle names.

Perhaps we can even allow payment type plugins to set a custom storage controller as well, to make it easier for payment types to provide CRUD operations, something which at the moment needs to be done by implementing entity event hooks, such as hook_payment_insert().

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented
Version: 7.x-1.x-dev » 8.x-2.x-dev
Status: Postponed » Active
xano’s picture

xano
he/they
Primary language English
Location Southampton
commented

Simply use context plugin IDs as payment bundles so contexts can use configurable fields to storage data.

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented

Required for #2047805: Port the payment form field.

pbuyle’s picture

pbuyle commented

Regarding having different classes for different bundles, the Entity bundle plugin module provides support for a per-bundle classes through (CTools) plugin (for Drupal 7). The idea is interesting, but there is really no need for a complex solution involving a heavily customized entity controller. The Strategy Pattern (https://en.wikipedia.org/wiki/Strategy_pattern) fits the need for per-bundle behavior perfectly (if any): a Payment is the Context and its bundle the Concrete strategy.

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented

Currently payments have a context plugin which defines the payment type. This will be expanded by adding a computed property that points to the plugin ID as the bundle, and by exposing context plugins as payment bundles. All context-related logic will remain in the plugin, but contexts can then add fields to payments to store their data in. This approach solves most issues that have arisen so far, and it does not deviate from how core does things, except for the computed bundle property, but that should be harmless.

pbuyle’s picture

pbuyle commented

That sounds great.

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented

Thing is, I need to find out the best way to implement this. Other systems may expect to be able to set the bundle on a payment by passing on a string to the bundle field. The actual bundle is defined by the payment's context plugin. I'm not sure whether to use a computed field for the bundle, or whether to store the bundle and plugin side by side and tell people not to touch them.

pbuyle’s picture

pbuyle commented

You could prevent edition of the context/bundle property by implementing it through __get() on the Payment class.

$manager = \Drupal::service('plugin.manager.payment.context');
$context = $manager->createInstance('foo_context');
$payment->setContext($context);
$bundle = $payment->bundle;
// $bundle is 'foo_context'
$payment->bundle = 'bar_context';
$bundle = $payment->bundle;
// $bundle is still 'foo_context'

You could also implement the bundle property assignation through __set() on the Payment class.

$payment->bundle = 'foo_context';
// will have the same effect as
$manager = \Drupal::service('plugin.manager.payment.context');
$context = $manager->createInstance('foo_context');
$payment->setContext($context);
xano’s picture

xano
he/they
Primary language English
Location Southampton
commented

We can't just do that directly. The property needs to be an entity field. See https://drupal.org/node/1806650 if you're not familiar with the new entity field API and typed data API yet.

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented

Entity NG only needs to set the bundle upon entity creation/instantiation. For payments this means that the context plugin ID is passed on on creation, and that the storage controller creates a plugin instance using that and sets it on the payment. PaymentInterface::bundle() can then return the plugin instance's pluginId() return value.

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented
Status: Active » Needs review
StatusFileSize
new payment_1896416_12.patch15.25 KB
xano’s picture

xano
he/they
Primary language English
Location Southampton
commented
Status: Needs review » Fixed
StatusFileSize
new payment_1896416_13.patch16.22 KB

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

The last submitted patch, 12: payment_1896416_12.patch, failed testing.