What IS the difference between this and Corresponding Node Reference?

CNR's maintainer has been very responsive to making improvements. Why do we need another module doing the same thing? If there are differences, please be explicit (esp in the project description, which is pretty unclear right now).

I'm fine if this is a different approach (CNR does have some quirks), but right now, it looks like this is a duplicate module.

Comments

jcfiala’s picture

jcfiala commented

I've actually been reading through CNR's code and testing it today, because I didn't remember it existed before. Apparently it had come up earlier, but at a time when it didn't handle single-references at all, and got forgotten.

The main differences seem to have to do with method - CNR doesn't seem to work with single-value or fixed-value fields, such as when you've got 3 values maximum for a nodereference, and backreference will handle that. It's willing to pretend that a multiple-value field is single, but that doesn't seem optimal to me?

sethcohn’s picture

sethcohn commented

Well, it doesn't just pretend, it essentially can limit items to a single reference (despite it being set to multiple, which is a design requirement of the module code, since it uses the idea that these are in a table by themselves, not part of the content type's table as a field. Only when the field is set to multiple does that happen.)

So BackReference will allow fixed number of references....This seems like the main difference (and a good one)

What happens if there are more than X number? (ie, we have 3 nodes (A,B,C) already linked to D (set to allow 3 references), and then I point node E to refer to D?)

CNR by limiting to single or unlimited multiple doesn't have to deal with this use case. (CNR's most recent code allows 4 options: 1to1, ManyToMany, 1toMany or Manyto1)

niklp’s picture

niklp commented

I'd still like to see more of this argument please :) [stealth sunscribe :P ]

nofuseto’s picture

nofuseto commented

For example you can use it with popups add 'n reference, which (at this time) has a nasty bug with multivalue nodereference fields that makes it unusable with cnr...

MMachnik’s picture

MMachnik commented

nofuseto -- I can't reproduce that bug, I assume you mean this one: http://drupal.org/node/388406

I have the latest cnr, popups, popups_reference, cck, etc. It seems to work fine for me. I click to add another item, which gives me a new node ref field in the form, then click Add New: Add (content type). Get the Popup, fill it in and submit, node reference appears in the field of the main node, submit that node and it works.

I tried to follow the steps in that bug report and as I said, could not get the problem to happen.

MMachnik’s picture

MMachnik commented

An update. I was trying something different. Today I was able to reproduce it. My repro scenario is:

* Click "Add another item" under a node reference field (autocomplete). Nothing happens.
* Then, click "Add New: Add (content type)" link to get the popup node edit form for the reference node. Submit the form. New node title is now filled in one of the blank node ref fields.
* Do this until all the node ref fields displaying are filled. "Add another item" still does nothing.
* Click "Add New: Add (content type)" link to get the popup node edit form again and fill in another one anyway. Submit the form. It replaces one of the existing nodes. Not good.

Workaround seems to be to just add one new node ref at a time and re-edit the parent node, but that's not going to do it long term.

thaddeusmt’s picture

thaddeusmt commented

I just tired out CNR and Backreference, and have to say Backreference is way nicer.

  • More tightly coupled with CCK: you can configure corresponding fields right when adding a Nodereference field to you content type. With CNR you have to go to a separate page, it's less intuitive.
  • Better control over the X-to-X relationships: CNR only lets you do many-to-many, 1-to-many or 1-to-1. You can do 3-to-many, 5-to-5, whatever you want with Backreference
  • More control over correspondence with multiple Nodereference fields: it looks like CNR automatically tries to choose which fields correspond. This was a problem since I was using multiple node reference fields on a single CCK type. With Backreference I was able to say which ones correspond to which more explicitly. Not a problem if each content type only has one Nodereference field.
jcfiala’s picture

jcfiala commented
Status: Active » Closed (works as designed)

Well, as this isn't so much an _issue_ as discussing two modules, I suggest moving discussion to http://groups.drupal.org/node/25554.

domidc’s picture

domidc commented

Corresponding node references version 6.4 makes cck handle the number of references http://drupal.org/project/cnr