"Lifting" of data- attributes from a field to its containing "view cell" ([quick]edit.module integration)

Sorry for the delay.

For starters, here is a reroll.

General patch perspective

As the issue indicates, the ideal would be that each view cell that contains a Field API Field automatically lifted any data- attributes added by hook_preprocess_field() implementations into the view cell's attributes.
If that can't happen, then modules like Edit need some way of 1) introspecting view cells' contents, 2) depending on those contents, set view cell attributes.

The current patch reviewed

The patch in #12 doesn't implement this automatic lifting of data- attributes. But how could it? After all, hook_preprocess_field() is not called at all — because this is "the Views render pipeline", not "the Entity/Field render pipeline".

So, consequently, the only way we could get the required attributes on each view cell, is by providing the ability to introspect each view cell's contents and then set attributes on the view cell. (In the case of Edit: essentially duplicate Edit's hook_preprocess_field() implementation to work with View cells.)
I tried to do this, and surely it is possible:

  public function getCellAttributes($row_index = NULL) {
    $field_name = $this->field_info->getFieldName();
    $entity = $this->view->result[$row_index]->_entity;
    $view_mode = 'views-' . $this->view->storage->id() . '-' . $this->view->current_display . '-' . $row_index;
    return array(
      'data-edit-id' => $entity->entityType() . '/' . $entity->id() . '/' . $field_name . '/' . $entity->language()->id . '/' . $view_mode,
    );
  }

Yay!

But this of course MAY NOT be hardcoded in Drupal\field\Plugin\views\field\Field. Modules should get the opportunity to apply logic such as that above. In other words: we need a hook.

Now, this is nigh identical to what I did for Edit module in #1962606-15: Quick Edit + "Field" Views (table, grid …) over 4 months ago: implement hook_preprocess_views_view_field(), where I calculated the data-edit-id attribute and set it:

+/**
+ * Implements hook_preprocess_views_view_fields().
+ */
+function edit_preprocess_views_view_field(&$variables) {
+  if (user_access('access in-place editing')) {
+
+    // Only annotate Field API View Fields.
+    if ($views_field instanceof Field) {
+      // Entity/Field metadata.
+      $entity = $variables['row']->_entity;
+      $field_name = $views_field->field_info->id;
+      $langcode = $views_field->field_info->langcode;
+
+      // Views metadata.
+      $view_name = $variables['view']->storage->id;
+      $view_display = $variables['view']->current_display;
+      $view_row = $variables['view']->row_index;
+
+      // Build edit ID; the view mode is now a hybrid that contains the
+      // necessary metadata for Views.
+      $edit_id = $entity->entityType() . '/' . $entity->id() . '/' . $field_name . '/' . $langcode . "/views-$view_name-$view_display-$view_row";
+
+      // @todo Push the rendering of the data-edit-id attribute deeper into the
+      // Views rendering pipeline instead of wrapping content in <span> tags.
+      $variables['output'] = '<span data-edit-id="' . $edit_id . '">' . $variables['output'] . '</span>';
+    }
+  }
+}

The only difference is that I now need to be able to set this "view cell attribute". The code back then did not yet have the ability to set the attribute, the patch in this issue does not yet have the ability to let other modules run it. But is it really worthwhile to fire another hook? Wouldn't it be simpler to just use hook_preprocess_views_view_fields(), but allow $variables['attributes'] to be set?
I don't know the Views architecture well enough to answer that.

To move forward

We have two options:

1. Allow modules to alter getCellAttributes() via a hook.
2. Allow hook_preprocess_views_view_field() to set $variables['attributes'].

Once we have either, in-place editing of Views will become as feasible as it ever will be.

A sister issue to enable in-place editing of Views in D8 contrib on the Edit side of things: #2083387: Make it possible to use in-place editing on entities rendered by a custom render pipeline (e.g. Views).

So yeah my idea was that a generic fieldapi field could set enough information so that edit (and other modules) can deal with it and don't need anything more. It seemed for me that entity-type entity-id field-name combination and maybe field-instance-id etc. would be enough and you don't need anything more.

That should indeed be sufficient metadata, as long as you also include view mode and langcode.

(no hook / other preprocess). From your comments this sadly doesn't seem to be the case. It would be great
to get some feedback whether you need a specific combination so that a generic solution can't work.

That's not what I said. What I said was that Views' code can't hardcode setting the data-edit-id attribute for Edit module. Hence Edit module needs some way — a hook, a callback, something — to take that metadata you mentioned earlier (see the above quote) and then turn it into the attribute that is desired.

So I think you might have misinterpreted my comment? (Or my comment just might be not sufficiently clear, of course.)

Still tracking this, but since we can't push this forward, not really part of the Spark sprint. The edit.module-side of this problem is part of this sprint because it's not blocked (by this or any other issue), we're working on that in #2083387: Make it possible to use in-place editing on entities rendered by a custom render pipeline (e.g. Views).

Booooo, d.o tag monster!

Third time's a charm!

(I hope.)

Updated issue summary.

Just FYI: the necessary API changes to make in-place editing of Views possible in Edit have landed in #2083387: Make it possible to use in-place editing on entities rendered by a custom render pipeline (e.g. Views). The only remaining blocker are the necessary API changes in Views, i.e.: this issue.