[Meta] Views Integration for field collection

This is a very much needed in this gr8 module

This is a very much needed in this gr8 module

Subscribe

subscribe

+

Maybe #1066398: Reverse entity relationships for Views integration can help here?

Subscribe

Subscribe

subscribe

Currently field collections shows up naturally in some views results, for instance as a containing entity for other fields. Is there any way with relationships to get that connection between node and attached field collection? If this connection can be made there would be a lot you could do with field collections right there. I've been experimenting but I haven't had any success.

+1 on what RobW said in #11

subscribe

Using the Field-collection item in Views, Grouping doesn't work. I get the following error when I sum a field...

'Exception: SQLSTATE[42S22]: Column not found: 1054 Unknown column \'field_data_field_qty.field_qty\' in \'field list\''
in views_plugin_query_default->execute() (line 1354 of /Applications/MAMP/htdocs/website.com/modules/views/plugins/views_plugin_query_default.inc).

sub

subscribing

Has anyone found a way to what RobW describes at #11? Get the connection between node and attached field collection with a views relationship?

For #11 and #17, take a look at this: http://drupal.org/node/1172372

It provides only the following:
1) Entity with Field -> Field Collections info.

It would be great to provide the base in vise versa:
2) Field Collections -> Load Entity Info.

However, the first Relationship does work with the patch for each Field Collection (as Field), and will provide the fields to you to use to filter/argument/display.

Note: When used in the direction of 1, you will have multiple entries per field collection. IE:

Node Title | NID | Field Collection Name | Field Collection Phone Number |
Node 1 | 12 | Greg | 1234
Node 1 | 12 | Jack | 1236
Node 2 | 13 | Jill | 1211

etc

Changed title for better overview in the dashboard.

Let's use #1172372: Add Views Relationship to Field Collection - patch attached for adding the relationship - which should do it for most-cases - and keep this as a meta issue.

Although, we might want to add
* a reverse relationship allowing views listing field-collections to join to a host entity of a given entity type (=config option).
* a filter that allows one to list field-collections of a certain host-entity-type (by adding a filter for the field table's entity type column)

I tested the patch in http://drupal.org/node/977890#comment-4564324 with views - the result is here

There's something I don't understand completely about the views integration...
Why is there the same form twice in views for the field collection field? (I mean, the configuration form is displayed inside itself, like if it was embedded... The attached screenshot speaks for itself...)

And as a feature request, is it possible to have each field of the field collection available in the replacement pattern token in views? Or simply as views fields...

Appart from that the views integration is excellent.

Forgot to attach the screenshot here as well, for #21.

I wanted to voice some concern about the direction field_collection has taken, ie.
http://drupal.org/files/issues/views_field_collection_configuration_form...

The disadvantage of the above approach as a formatter is that each field in the field_collection structure is not exposed in the view; thus we could not really take advantage of views to take care of the rendering process of the fields inside the field collection structure but instead we are stuck in a static version of doing every field inside a formatter kinda like field_collection_table . Please take inspiration from cck multigroup which exposes the fields inside the multigroup and having the correct sync of it by adding a multigroup filter.

kind regards,
chriscalip

Regarding the duplicate issues reported in #18 :
That's inherent to the fact that you have a relationshionship on a reference field with multiple values. That creates a JOIN which returns several rows for the same parent node. You'll find the same behavior with node_reference relationships on a noderef field with multiple values. Problem is that field_collections will by definition always be multiple.
node_reference works around this by using a dedicated relationship handler that has a user option to restrict to a given delta. Not entirely satisfying though.

Regarding the garbled field_collection field settings form in views reported in #20 / #21 : see #1227244: Bug in formatter settings in Views

there is patch for having the Entity relationship for the field collection.
i use the solution from node reference, the reverse reference case (views_handler_relationship_entity_reverse - relationship handler)

it works for me. please review

#25: [Meta]_Views_Integration_for_field_collection-1047784-25.patch queued for re-testing.

Working fine for me, but manually applied it after seeing testbot had troubles (and it's such a tiny patch)

I think the testbot is broken due to #709464: Don't test core when testing contrib. There is a whitespace issue however, so marking needs work. I hope to have time to test this soon.

subs!

I tested this on a view based on profile2 with an unlimited field-collection field. By adding a relationship to the field-collection, I was able to list each field within the field-collection as a separate row in a table and it was exactly what I needed to do. So, this is working fine for me too.

#25 works for me as well

http://drupalcode.org/project/field_collection.git/commit/dd2ad60

Committed, thanks!

Hi guys, I am pretty new to drupal and recently used your field collection module in my product catalog.

Its an excellent mod, but i want the table view should appear in vertical manner than horizontal. In my product i have about 16 fields which forces user to scroll horizontally.

Is it possible?

Patch generally looks good (except for the whitespace issue), however we should not implement the alter hook ourself, as this way other modules don't have the possibility to do alterations any more (without depending on the right order..).

Providing new array-keys works anyway with the main hook, so couldn't we just use the main-hook here? module_implements() merges together the results for us anyway.

Well I tried to fix the whitespace before committing, but I left out a space I guess.

I will look at fixing this today if I can, and I can ask kleinmp to test it again.

I'm going to let this sit for a little while to see what the response is on #1291088: Recursively merge field views data, but here is a patch to clean up the code in the meantime.

Note, this pattern follows image module's views implementation, but in that case, image_field_views_data_views_data_alter() is operating on a table it doesn't own, file_managed, whereas we're adding to our own table.

adding relations to the field collection relation seems to create problems, I can't add a file usage relation (to get e.g. file path) and when I add a node reference based relation to my field collection relation it results in column not found (Unknown column 'very_long_field_alias.nid' in 'on clause').

I'm having the same issue as HnLn it seems. Updating to the latest views-dev introduced the unknown column error.

Patch of #38 looks good to me in order to address #36. -> setting rtbc.

@#39,#40: Please open a separate issue for that. Let's only link issues from the META issue.

Oh, that other patch got into Views. Will need to rework this.

This shouldn't be committed until Views 7.x-3.x-rc2 is released.
You can use this now with a Views dev after November 1st.

Has this been comitted? It has prevented a few errors I was recieving.

There is now a Views RC3, so I committed this.
http://drupalcode.org/project/field_collection.git/commit/790c8a9

Here's some issue I'm having with this functionality in the final release version of Views: #1379008: Reverse entity Views relationship not associating with node field data

In my experience, it doesn't seem to be working correctly again (see related ticket for my problems/thoughts). Can anyone verify this?

Let's leave this closed as it was a long running issue that did too much. Thank you for opening a new issue, I will take a look at it when I can.