I have nodes of three types: Artists, Albums, and Songs. These are connected by Node Relativity relationships -- Artists are parents of Albums, Albums are parents of Songs. I want to create a fused view that has all Songs in all Albums by a particular Artist, with basic info culled from the fields for each. Something like this:

Album Title Year Song Title Duration
Rubber Soul 1965 Drive My Car 2:30
Rubber Soul 1965 Norwegian Wood 2:05
Revolver 1966 Taxman 2:39
... ... ... ...

For the primary view, I set it to find all Album nodes, with an argument for the parent (Artist) node, and display fields Node: Title and Year in Table View. For the secondary view, I set it to find all Song nodes, and display fields Node: Title and Duration in Table View. I then fused them using the Node Relativity: parent-child relation (using a patch to Node Relativity).

This fused view displays exactly as desired. However, the Node: Title links are not working right. In each row, the links under Album Title and Song Title both point to the Album node. Just to make sure, I loaded the secondary view by itself, and there the links under Song did in fact link to the Song node. I guess that, in creating the query, the whole row is tied to the Album node, so when Node: Title shows up under the Song Title heading, it resolves as the Album node. Removing the (Album) Node: Title field from the primary view does not fix the problem; the Song Title still links to the Album node.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tortoise’s picture

Priority: Normal » Critical

After poking around in the code, I believe that any field whose views_handler_field_ function requires the use of the $data parameter is going to fail in a fused view, as $data will refer to the node in the primary view when it gets passed to the handler. This includes Node: Title links (and other Node links), Node: ID, Node: Edit, and Node: Delete. Somehow, the node being looked at in the fused view must be remembered when it gets fused to the primary view. I don't know a whole lot about the inner workings of Views and Views Fusion, but it seems that one way to fix this would be to check if a field in the fused view falls into one of the above cases during the merge, change $field['queryname'] to get the fused node's nid, and change $field['handler'] to a special-case version of the normal handler which loads the fused node from the nid and uses the desired information from the full node. However, this requires a node load for every row in the view, which is an undesirable overhead. Is there better way to make this happen?

liquidcms’s picture

yup, lots of bugs in fusion.. this would be another one.

thank god for Views 2!!

liquidcms’s picture

Title: Node: Title links not working right in fused view. » Title links not working right in fused view.
Component: Miscellaneous » Code
Status: Active » Needs review
FileSize
1.54 KB

this might help a bit.. played around with it a bit and can't believe i have never seen this before considering how many fused views i have made in the past.

seems like certain field handlers tell views to do things like grab NID directly rather than look at the fused values that get added to the field; my approach which i haven't tested too much was to basically let VF add its own handler for certain fields and then make sure it puts in the right values.

liquidcms’s picture

FileSize
2.03 KB

this also adds the vf handler for node edit.. likely a much better way to do this that add all the views handlers... maybe i am missing something here??