[development] Crossing information between content types

Yuval Hager yuval at avramzon.net
Wed Oct 24 11:46:21 UTC 2007


Hi all,

Let's say I have two content types - a person and a bank account. A person can 
have several bank accounts, and a person also has an address. 

Now I need to present a listing if all the people who live in New Jersey and 
have more than $100k in their bank account. In any database application it 
would be dead easy - just use a SELECT.. JOIN on these two tables and you're 
done.

However, on Drupal, I am not sure what is the best way to accomplish that.

First thing I did was to define these two content types in CCK, install the 
relativity.module and declare parent-child relationships between the person 
and her bank account.

Then I hit the wall.. I can't combine information in a view from these two 
content types, and I can't use views fusion module, as it doesn't know about 
relativity (only nodefamily).

My dream solution would be to expose relativity.module into the views admin 
screens, and just add/filter the fields of the related content types. But 
since relativity is generic and views uses a flat view of all fields, I 
really can't think of a way to accomplish that cleanly.

Of course I can write the query myself, but since these are CCK nodes, I can't 
use a direct SELECT, and have to iterate through the nodes manually. It is 
also not maintainable through the UI being strictly in code (and can't use 
views plugins etc.).

Another option could be to use views hooks (pre_view, query_alter..) to load 
the parent node, check the condition and manipulate the view accordingly. 
This doesn't feel right neither.

I ended up going back to my dream solution and face it with reality. Since I 
know my CCK structure and the queries I need, I can go specific. I created a 
module and added the 'location' table, but not connected to the 'node' table, 
rather to 'relativity' table, through the 'parent_nid'. This way I can add 
the parent-city as a field, filter and an argument to the view. As a bonus, I 
even reused the original location.module city argument handler. The downside 
is that it's quite a lot of code (although once written can be managed 
through the views administration).

Does this make any sense? Isn't there a simpler solution?

Cheers,

-- 
Yuval Hager
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.drupal.org/pipermail/development/attachments/20071024/261998c8/attachment.pgp 


More information about the development mailing list