This example use case in the module's front page:

Example

Node type A has a node reference to node type B and node type B has a node reference to node type A. When you create node X of type A and reference it to node Y of type B Node Y will also receive an update in its node reference field pointing to node X.

...is rather confusing.

Can we please have a real life use case example? Any of the ~900 people using it care to tell us how they use it?

Comments

Anonymous’s picture

I'm using this module in two ways:

1) I'm running a site, where I'm tracking work reports for my customers. I creat a customer node and reference all work reports to the customer. I can navigate from the customer to all it's reports and from each report to the customer

2) I'm connecting related reports to each other, for example reports, that are related because the same problem occurred twice.

klonos’s picture

Title: Real life use case example please? » Real life use case example please? + Difference between this module and CCK's noderefernce

Thanx for taking the time to reply Earl. This example does make a lot more sense to me now, but I'm still curious to see how others use this module. Care to share the URL of this site of yours? (or at least PM me with it).

In order to have this issue marked as fixed, I would first like to see one of the examples posted here also be posted in the module's front page. Preferably, it will be the simplest of the examples in order to help others grasp the purpose of this module easily, simply by looking at a 'Consider this use case scenario...' section.

klonos’s picture

+ as I state in the issues title change, I'd like to see a section in the module's front page stating the way it complements the CCK's nodereference submodule. In other words something like this in the module's description: 'The nodereference submodule that comes with CCK helps create... , but there is no easy way to link back to the... This is where Corresponding node references comes in. Once installed and enabled it...'

domidc’s picture

Status: Active » Closed (works as designed)

What is there not clear about this?

It syncs the node reference between two node types which have a nodereference to each other, so double editing nodes is no more needed. If one node has a reference the other node receives also a reference to the saved node if it is referenced in that node.

It also states the dependency on cck and nodereference that comes with it.

I believe everything is as it should be

klonos’s picture

Fair enough Dominique. But what I was trying to achieve is make this understandable by any Drupal newcomer and not people that are really familiar with the terminology. In other words I was aiming for something like this:

'Consider the following real life example case... Using nodereference alone, one would face the issue of... This is where this module comes in! It allows...'

Such an example would help people decide if this module is the right one for their use case. Get my drift? Anyways, I won't argue any more over this one.

domidc’s picture

Status: Closed (works as designed) » Reviewed & tested by the community

Yes I onderstand your intentions. Had not looked at it that way, we could add your real life example. Sorry was maybe a bit too fast closing the issue. Thanks for the extra explanation.

klonos’s picture

Had not looked at it that way...

Never mind, that's when being a large community helps. If one doesn't see it, then somebody else will ;)

Thanx for (re)considering this. I'll try and come up with a nice and simple to understand example that covers all features of the module. Once I do, I'll post it here (unless somebody else beets me to it of course) and then all you'll have to do is copy/paste it with perhaps any editing you might see fit.

domidc’s picture

Great. Thanks!

zhahai’s picture

If I'm understanding you, in one case you are using the module to create backlinks between two different node types, and in the other you are using it for links within the same node type (reports).

If so, this could be simply described as:

"When you create a node reference from node X (of node type A) to node Y (of node type B), this module will create a backlink node reference from node Y to node X, if such a node reference is defined for node type B linking to node type A. Node types A and B can be different or the same."

The current description sounds as if they have to be of differing types. If that's true, it needs to be stated clearly; if not and the above description fits, perhaps it would help in clarifying to use it.

Then a real word example of both different and same node type cases might be icing on the cake.

slippast’s picture

zhahai: That wording may be a little confusing but CNR will maintain a reference to same node types and different node types, as long as they're turned on with the Reference field is created and then enabled in CNR.

So, for example, content type 'blog' can reference 'blog', 'slideshow', 'article', etc. Nodes can even reference themselves.

slippast’s picture

My use case for CNR is pretty straight forward: I'm building a site for a TV station where I import TV program data that has two content types: Series and Episodes. The Episodes are singly related back to the Series while the Series will have references back to all of its Episodes (basic parent/child).

I take it several steps further by adding other content types like Slideshows which can be linked to multiple Episodes and Series and Sponsors which can be linked to anything. I have other content types that are all interlinked as well. It gets a little complicated which is why you need to map the content structure before you start building the site.

CNR makes Drupal Nodes aware of each other and allows content to function sort of like a relational database. The References module is a great tool but I find that if content isn't back-linked with CNR it sends people down one way streets. This functionality should be part of References. The downside is that I haven't been able to get Views to play along the way I'd like so I've written a number of custom modules and a lot of template preprocessing. The upside is that with everything being aware of related nodes with CNR it makes displaying data from multiple node types much easier.

I think that the lack of a relational content architecture in Drupal is a huge shortcoming and the fact that I've had to write as much custom code as I have to make my site possible is frustrating. CNR really helped close some of those gaps though.

klonos’s picture

Version: 6.x-3.3 » 7.x-4.x-dev

...I'm pretty sure that a screencast that would demonstrate a very basic/simple example reference between two node types would suffice.

domidc’s picture

Status: Reviewed & tested by the community » Closed (won't fix)

No new documentation will be added. New features can be posted on http://drupal.org/project/cer which is the next evolution of cnr.

klonos’s picture

Thanx for taking the time to explain Dominique.