Since #1172970: provide a unified way to retrieve result entities we have the possibility to do query-backend agnostic entity-related views fields that work with loaded entity objects provided. Thus, a module can provide a views-field now that works across all backends, but discovery, assignment to the base-tables has still solved manually.

Goal:
A module should be able to provide a views field dedicated to a certain entity-type which then automatically is available regardless of the query-backend used (e.g. search api).

Proposal:
* Add a hook that allows modules to provide views-fields related to entity-types, e.g. hook_views_entity_data()
* Add in that data to the regular views-data dependent on the entity-type.

CommentFileSizeAuthor
#23 views-entity-related-views-field-1270890-22.patch6.79 KBBlackice2999
#22 views-entity-related-views-field-1270890.patch5.85 KBBlackice2999
#17 views_entity_tables.patch4.95 KBfago
#15 views_entity_tables.patch4.51 KBfago
#13 views_entity_tables.patch4.26 KBfago
#11 views_entity_tables.patch3.69 KBfago
#10 views_entity_tables.patch3.72 KBfago
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

fago’s picture

fago
Primary language German
Location Vienna
CreditAttribution: fago commented

also see the related issue #1266036-1: Add generic Views entity tables with fields and relationships

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
CreditAttribution: drunken monkey commented

Subscribing.

The hook would then get $type as an argument, right? Sounds reasonable, and shouldn't be too hard, I guess.

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented

In general this is a great idea, but i'm wondering just a bit how this should work technically.

If search_api provides general entity data, then for example the node data would have fields both from node_views_data and search_api, which could confuse some users: for example you might have node title + node label, but this is probably just some kind of documentation/labeling issue.

In general after the initial views data collection you could iterate over each table and look for 'entity type' base key and merge the data in, does this make sense? This should work.

fago’s picture

fago
Primary language German
Location Vienna
CreditAttribution: fago commented

The plan is that search-api does its own base-tables as now, but that those entity-related fields are applied to all base-tables belonging to a certain entity-type. So search-api should not provide its fields that way, but receive some additional entity-related fields via it.

In general after the initial views data collection you could iterate over each table and look for 'entity type' base key and merge the data in, does this make sense? This should work.

Exactly. However, there is no good timing for doing so, as alterations should be possible too. So having a separate hook + views applying it to the base-tables would be the cleanest way I think. Also that way we could migrate the node edit/delete links to use the hook too.

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented

Another solution instead of the hook is a global "table" like $data['global'] which is joined to each entity table.

So if you show a node or a user you will always see the fields from this entity table.

fago’s picture

fago
Primary language German
Location Vienna
CreditAttribution: fago commented

Well, I think we need per entity-type global tables, thus something like "views_entity_$type". So we can have per-entity-type fields that are available for all base tables that use this entity-type.

But yes, +1 for that approach :)

BenK’s picture

BenK CreditAttribution: BenK commented

Subscribing

fago’s picture

fago
Primary language German
Location Vienna
CreditAttribution: fago commented
Title: provide a hook for entity-related views fields » provide a way to provide entity-related views fields
Assigned: Unassigned » fago

I'll roll a patch for that asap.

jakonore’s picture

jakonore CreditAttribution: jakonore commented

subscribing

fago’s picture

fago
Primary language German
Location Vienna
CreditAttribution: fago commented
Status: Active » Needs review
FileSize
views_entity_tables.patch3.72 KB

so, finally I've come back to this and rolled the patch - see attached. Works for me.

Added docblock comment should explain how it works.

fago’s picture

fago
Primary language German
Location Vienna
CreditAttribution: fago commented
FileSize
views_entity_tables.patch3.69 KB

fixed the patch to keep working in case of multiple entity-type tables.. :)

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented
Status: Needs review » Needs work 
+++ b/modules/node.views.incundefined
@@ -232,9 +232,11 @@ function node_views_data() {
+  $data['views_entity_node']['view_node'] = array(

If you define a 'moved' key the fields will work on old views as well.

fago’s picture

fago
Primary language German
Location Vienna
CreditAttribution: fago commented
FileSize
views_entity_tables.patch4.26 KB

ok, I've worked on basing #1209678: Add a Views field handler to display rendered entities and the entity-row plugin upon this. I realized, we also need to add an entity-type to the new views-entity-TYPE tables + initialize $this->entity_type upon init() for the entity-field handler, so one can make use of the entity-type in the options form.

Updated patch attached.

ad #12
How does that work exactly?

tnightingale’s picture

tnightingale CreditAttribution: tnightingale commented

subscribing

fago’s picture

fago
Primary language German
Location Vienna
CreditAttribution: fago commented
Status: Needs work » Needs review
FileSize
views_entity_tables.patch4.51 KB

ok, found it myself. Keeps old views using that fields working for me - useful and important feature! :)

clemens.tolboom’s picture

clemens.tolboom
Primary language Dutch
Location Groningen, 🇳🇱/🇪🇺
CreditAttribution: clemens.tolboom commented

I'm not sure this is the right issue but I miss an entity related argument.

Say I want to add an local tab on every entity view say node/%/annotate, user/%/annotate taxonomy_term/%/annotate
(My projects issue #1317690: Support annotation for any entity)

Is this issue also about entity arguments? If not should I create one for this?

fago’s picture

fago
Primary language German
Location Vienna
CreditAttribution: fago commented
FileSize
views_entity_tables.patch4.95 KB

ad #16: nope, please create a separate issue for that.

At #1266036: Add generic Views entity tables with fields and relationships we stumbled over another small issue with the generic entity field handler: It doesn't respect the 'base field' of relationship definitions. That's required to support non-base table entity-tables as we've created over there. I've updated the patch to include this small fix.

fago’s picture

fago
Primary language German
Location Vienna
CreditAttribution: fago commented

Further improvements:
* Fixed call to get_result_entities() to not pass an additional, unnecessary, undocumented parameter. Looks like an left-over from old code - sry for that.
* Improved get_result_entities() docs based on the docs included in #1266036: Add generic Views entity tables with fields and relationships

Tested re-using the node-link-fields together with #1266036: Add generic Views entity tables with fields and relationships and search api views integration, works great (including relationships)!

mh86’s picture

mh86 CreditAttribution: mh86 commented
Status: Needs review » Reviewed & tested by the community

Tested patch from #17 with a few scenarios:

  • Updated an existing view with node edit links (tested 'moved to' key)
  • Added node edit links to a search api view
  • Used Rules Link on a search api view with some relations (in combination with #1264258: Update to latest views changes)

All of them worked fine for me and the code looks clean as well.

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented
Status: Reviewed & tested by the community » Fixed

Thanks for writing/testing and reviewing the patch!!

Commited to 7.x-3.x

Status: Fixed » Closed (fixed)

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

Blackice2999’s picture

Blackice2999 CreditAttribution: Blackice2999 commented
Status: Closed (fixed) » Needs review
FileSize
views-entity-related-views-field-1270890.patch5.85 KB

Hi, i am not sure if needed but here additional for user entity

Edit:
ups it seems that all patches was sent for Re-Test ? - If it was wrong to add the patch here please short notify me and next time i open a new issue.
Sorry

Blackice2999’s picture

Blackice2999 CreditAttribution: Blackice2999 commented
FileSize
views-entity-related-views-field-1270890-22.patch6.79 KB

sorry i forget a dpm()

new patch:

dawehner’s picture

dawehner
Primary language German
CreditAttribution: dawehner commented

Part of the code is really similar to what #1859884: Convert user link fields to use entities does.
In a world with a generic views integration using information from the entity storage, would we still use this extra table or would we still use links on the "users" table?

clemens.tolboom’s picture

clemens.tolboom
Primary language Dutch
Location Groningen, 🇳🇱/🇪🇺
CreditAttribution: clemens.tolboom commented 
+++ b/modules/user/views_handler_field_user_link_edit.inc
@@ -11,17 +11,14 @@
+    dpm($values);

Remove this dpm too ;)

fago’s picture

fago
Primary language German
Location Vienna
CreditAttribution: fago at drunomics commented
Assigned: fago » Unassigned
Issue summary: View changes
Status: Needs review » Closed (fixed)

This has been fixed, any follow-up should be filed as a new issue imo.