Allow the view in the OrderItemTable formatter to be configured

This seems like a very useful feature thanks.

I have a suggestion. It could be useful also to allow configuring the display ID (currently the default display is always used). At the moment you have to duplicate the entire view even if you only want one setting different.

What does anyone think of that?

I have reviewed and tested the latest patch - all looks good.

It would be great to get this in to support Drupal Symfony Mailer relating to ✨ Full integration with commerce module Fixed .

Would be great to expose a setting for the display so we don't come back to this later!

@jsacksick: What do you mean? There is a setting:

+    $elements['order_item_view'] = [
+      '#type' => 'select',
+      '#title' => $this->t('Order item table view'),
+      '#description' => $this->t("Only views tagged with commerce_order_item_table are displayed."),
+      '#options' => $available_views,
+      '#required' => TRUE,
+      '#default_value' => $this->getSetting('order_item_view'),
+    ];

There is no setting for the Views display ID? Only the view?

Ah! Got it. An echo of #36.

I admit I was confused by this one, at least until I wrote a big long comment explaining why I was confused and then realized: we're talking about a site with multiple Order types, right? If I've got five different Order types with five different needs for Order Item display, we DO NOT want to "make five different custom Views", but rather add four more displays to our currently selected View?

Gotcha. That makes sense.

I tried exposing an additional setting for the display ID but adding #ajax to the formatter settings form isn't as straightforward as I thought. The code I wrote works on the manage display form, but either breaks with Layout builder or when configuring the formatter within views.

When introducing ajax to configure the view display, we then have to take care of clearing the display input as the selection is in theory invalidated by the view selection (otherwise we end up with the infamous "An illegal choice has been detected")...
Additionally, the #parents array isn't available when the form is built which adds some additional complexity when it comes to fetching the view that is currently input.
Tried adding #process and #after_build callbacks, and it works in almost all cases but when playing updating the view selection back & forth I ended up with errors.

So I'm thinking we should this as is for now as I don't have time to look into this further atm... Will still post an updated patch with some changes to the dependency injection (injecting the entity type manager instead of the view storage directly, defining the schema for the formatter settings etc...

Maybe I should revert the setting name to "order_item_view" for people already relying on this patch. Then thinking we should address the display as a followup, if it even becomes a "concern".
Thoughts?

I had the same worries about the #ajax stuff and was going to bypass it by formatting the options as "view_id: display_id".

Committed the patch from #42, thanks everyone!!

Great thanks. I raised 📌 Allow the view display in the OrderItemTable formatter to be configured Active for the follow up.

Perfect, didn't want to delay this feature further which is why I think it's a good idea to handle the display configuration as a followup.

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