relationships

I have two node types - A and B. B has a nodereference to A, thus one A (parent) has many B children:
A1
|-B11
|-B12
|-B13
...

A2
|-B21
|-B22
|-B23
...

I need a view that displays a row per A-node along with one of A's children (the first, a random, etc.). Example:

A1 B11

A2 B21

A3 B31

I saw a podcast showing how to do the reverse: for each child, use the Views relationships to show the parent's title for example. That's clear but I need it top-down: for each parent show one child. How can I do this with views?

I would be very interested in a workshop session at DrupalCon on relationships. I think there are many people working in this area, and I would really like to know where we all are.

I have been building some "social mapping" sites over the last year, and have many lessons to share. (http://nm-x.com and http://www.l-atlas.net are some examples) I would also like to perhaps find a group to collaborate on actually building the relationship api we have been talking about for who knows how long.

I registered a drupalcon session. Maybe, we can get it scheduled and have a chat ?

"Relationship" I understood as relationships between fields (nodes are many relationships, which are subject of more advanced process).

Wanted features:

1. Powerful and without limitation thanks to the most abstract (see: "everything is a field", compare this to: Global CCK fields, A controversial(?) point: store translations as nodes).
2. Build-in categorization features.
3. Build-in views features (listing fields, not necessary nodes).
4. Build-in menu features.
5. Support for Semantic Web/Microformats/similar.

Observations about current situation:

As I've already posted, I'm working on nodeprofiles as summer of code project - project page. Now I've some first code you might be interested to test.

I'll try to give you a short overview of the modules I built:

usernode.module - Automatically creation of usernodes
nodefamily.module - Builds nodefamilies based on content types and author information
nodeprofile.module - Marks content types as profiles

check the readme or my site for more detailed information.

Before reading this post, check out my thoughts on how to implement a new taxonomy system using CCK. It figures into my idea here as well:

http://groups.drupal.org/node/246#comment-1625

Proposal: A theme/module that manages each *.tpl.php file for the site admin by storing the layout in the database. For each handled hook (aka hook.tpl.php), the system would create a CCK type. The type would contain a Title and a text field. The textfield would be the place where the admin could enter the theme code. Each *.tpl.php would just be a shell to pull in this data from the currently selected node.

Boris suggested I cross-post this here (originally posted http://drupal.org/node/69957)

We are building out functionality to allow multiple locations associated with a content node. The idea is to make location nodes, changing nothing to the location module, but making a new module which will facilitate in the creation of and association between location nodes to their content nodes.

there's are a few issues in the project module's queue (http://drupal.org/node/44162 and some duplicates), about how to link different issues together and record relationships between issues. so far, we've been talking about issues from the project module, but the ideas are generally applicable. i thought people interested in the issue tracking and relationships groups might have ideas. a few potential use cases:

1) recording the duplicate issue id so that a) we can automatically add a comment to the "parent" issue that another duplicate was just created (which bumps the issue's access time, since effectively the duplicate means another instance of the issue was just noticed), b) we could have a block of links in the parent that showed all the duplicates, and c) we have a consistent way to display the parent issue inside the child...

One of the things I came away with from the Vancouver DrupalCon, is that we already have our relationship API, in the form of CCK and what I want to do with forms 2.0.

Firstly, in forms 2.0, there will be 2 discrete steps.

Step 1: Defining Fields for form. (or node type, or whatever)
Step 2: Placing these fields within their final form structure (add tables, fieldsets etc).

Now I am basing this functionality off of the cck field definitions, so that all the validations and field type
code will be built using cck, and one of these field types is 'nodereference'

CCK already handles all the 'has, can have and single / multiple' bits of the relationship api, and with