It is a strong use case IMO ... We shall see this solved when Views2 and node_reference are playing nicely together. I would think that the node ref form will add a section where you select the fields from the referenced node that you want exposed in Views. Then noderef and content.module will work with Views2 to expose just those fields. This resolves the UI clutter issue. We need Views2, so this won't be solved immediately. I'm sure Earl would love some testers and documenters to help on that Views2. Start by reading http://www.angrydonuts.com/views_2_high_level_design and http://groups.drupal.org/views-developers On 10/25/07, Yuval Hager <yuval@avramzon.net> wrote:
On Thursday 25 October 2007, Moshe Weitzman wrote:
The CCK developera re always one step ahead. They have some helpful functions for building joins that will work even if a field changes its multiple status or you do an upgrade. Here is an example "safe" join:
$field_bw = content_fields('field_blog_weight'); $db_info_bw = content_database_info($field_bw);
$sql = "SELECT n.nid, n.title FROM {node} n JOIN {". $db_info_bw['table'] . '} bw ON n.vid=bw.vid';
I *knew* this form of abstraction exists, I just never got around to it yet. Thanks for the pointer.
I am still thinking how can this sort of queries can be exposed to the UI. I believe the natural place is views, but am not sure exactly how. The straight forward way would be to make all parent's fields/filters/args available in the views admin screens. I see two problems with this approach: (o) The list of fields will quickly be cluttered by tons of 'Relativity: Parent of <something>: <something else' fields (o) I am also not sure this is at all possible. It requires adding all the relevant tables through relativity.parent_nid instead of node.nid, and reuse all the filter and arguments handlers..
Any other thoughts?
OTOH, maybe the use case is just weak, so this is really a non-issue..
-- Yuval Hager