[development] Crossing information between content types

Moshe Weitzman weitzman at tejasa.com
Thu Oct 25 11:58:49 UTC 2007


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 at 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
>
>


More information about the development mailing list