A use-case documentation of Node Relationships

Issue Summary

I've been experimenting with the modules noderelationships and nodereference_views. These two works very well in tandem, the only awkwardness is the need to open a lot of modal windows to create nodes that are needed downstream.

Example:

I would like to create a track from an album. I have several content types: Track, Album, Role and Artist.

The Role is a content type which links an artist to a role, which is specific for this album; thus I would use a flexifield, for this and create a view to attach to collect all the backreferences from albums the person appears in. Unfortunately the extra widgets which noderelationships adds to the nodereference field is not retained when used within a flexifield; so my only option is to nodereference Role from Track.

The Album has a nodereference to Track which is unlimited and where I'd configure noderelationships to add extras (found at the url /admin/content/node-type//relationships/noderef) like "View reference in new window", "Edit reference" and "Create and reference". Be sure to set the "Search and reference view" you would like to use. Pro tip: You can add a view display to the existing view by clicking the "Edit view"-icon to the right of the View-dropdown. This can be useful if you want to add a display which shows images, media or other info you need; as well as filters.

The Track has a nodereference set to Role.

The Role has a nodereference set to Artist as well as a taxonomy vocabulary "Role".

Now, to create the track I would first have to create the album. In the nodereference field to tracks there will be one line, and additional widgets. One of them is to create a new track.

Up pops a modal dialog that lets me create the track. In the nodereference field to roles there will be one line, and additional widgets. One of them is to create a new role.

Up pops a modal dialog that lets me create the role. And this repeats itself for the nodereference to person. After creating the person, I am able to save the person node, then the role node, then the track node, and finally the album node. Of course, at any point I could add more of the downstream nodes.

A note to anyone creating this kind of application. I would add yet another content type Role set. It would be pretty tedious to add all the roles manually for each track, especially if it is the same people every time. The nodereference to Role could be modified to accept both Role and Role set content types.

The Role set would have a list of roles, you could call this a group, as in a collection of artists performing together on a (semi)permanent basis, which you wouldn't have to enter manually every time.

Perhaps even an Group would be apropriate, add start year and end year, to show the time the group was assembled etc. And modifiy the role reference in Track to also allow content of type Group.

But I digress, the point here is that there is a lot of modal dialogs going on.

Now to the icing.

There is a first layer of icing, namely noderelationships' backreference views. You can select any view (as long as it is tagged "noderelationships_backref") as the backreference. Therefore, in a Group node you could enable the view Group performs on these albums in /admin/content/node-type//relationships/backref.

This is pretty nifty, as you can now add a view showing the album cover of each album, order it by release year and bob's your uncle.

The second layer of icing is the nodereference_views. The title is a bit misleading, as it omits the important keyword "formatters". In the Content management, Display fields tabs (/admin/content/node-type//display) you can select the formatter for your fields, among them the nodereference fields.

The nodereference_views ads a formatter called "View" to the list of available formatters. This assumes you have created a view with the name of the field, so for the nodereference field field_tracks, you would have to create a corresponding view field_tracks. And you now have total control of how you present this field in your node!

Add into the mix: computed_field and you'll have a very powerful solution for almost any use case.

I'm envisioning using computed field to import data from dbpedia, imdb or similar (unless the module createfromweb starts working again and gets all the plugins working).

I used the same text as a review on drupalmodules.com and as a comment to an issue in Flexifield, which I will no longer be needing at all: #368262: Request for configuration option to save flexifield items as nodes. I post this here as a documentation issue; in case someone would like a little recipe for doing very useful stuff with your module. I hope that anyone who finds this useful will comment in this issue :)