Configure path arguments for View widget via UI

Thank you! Patch looks good to me. Would be nice to add some test coverage though.

Re-rolled and added the missing assertion.

(by the way, I assume the missing test was just for the UI addition, not for the functionality itself :)

Rerolling against the current version.

I'm bumping this up to 2.x since it applies cleanly, and that appears to be where all the modern development for this is heading.

The patch still applies to the 8.x-2.x branch after the removal of ctools ui.

Here's a screenshot of the ui for the widget config form with this new field:

The validation works well, uses javascript.

It saves to the config fine.

The schema looks right for integer only arguments.

entity_browser.browser.widget.view:
  type: mapping
  label: 'View widget configuration'
  mapping:
    submit_text:
      type: string
      label: 'Submit button text'
    auto_select:
      type: boolean
      label: 'Automatically submit selection'
    view:
      type: string
      label: 'View ID'
    view_display:
      type: string
      label: 'View display ID'
    arguments:
      type: sequence
      sequence:
        type: integer
        label: 'View display arguments'

Here's one odd thing, when you remove the arguments and resave, it saves an empty arguments array where there was none before:

widgets:
  6159e5d9-cea8-426f-a71a-c5d2533974ab:
    settings:
      view: full_width_breaker_embed
      view_display: main
      arguments: {  }
      submit_text: 'Select Breaker'
      auto_select: false

Here's it in action, and this took me by surprise. The arguments are not integer arguments to the view, but rather integer arguments that map to parts of the path. I was testing with an entity embed, so this is what I got:

This is interesting because in this context, I would think it might be more useful to have the original node's node id, if available.

This is where this gets problematic. If you have it on an entity reference field, it would only work once the node is saved, I would think. Otherwise, node/add/article, you'd get "add", where you might want to pass the node id to the view.

I don't remember how views behave, but I wouldn't be surprised if it's expecting an integer (from node/1234/edit) and it gets an a string from node/add, it would throw an error.

I think the help next needs to be clearer that you're adding parts of the path from the page that launches the entity browser.

Also, we need test coverage for this form as well as the behavior of the view widget plugin pulling in URL arguments.

Another thing that should be clarified is that the path parts are not zero based. If you want the node id, you'd need to put 2, instead 1. Which is odd given the history of drupal's arg() function and how many things in programming are zero based.

I have some code in a related issue that would return the original path in both the context of a field widget and an entity embed. See https://www.drupal.org/project/entity_browser/issues/2790951#comment-129...

I think we could probably combine the two issues. That patch adds a hook that allows altering the view (including the arguments) before rendering.

Reroll of #7 only.

After testing again, I think this approach makes less sense than 2865928 and 2790951.

• #2865928: Provide method for views widget to filter based on context
• #2790951: Provide for contextual filter argument option on field widget

Url argument path parts are more fragile than getting target_bundle and original entity route.

Even though the module supports url path part conversion to arguments already, I don't think this is the most stable way to get context to the view.

Uploading a reroll of the patch that applies cleanly on version 2.9