[development] Crossing information between content types
yuval at avramzon.net
Wed Oct 24 11:46:21 UTC 2007
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
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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
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