How is this different from the node relativity module?

I've personally never tried this module, does anyone want to let us in on how it works/differs...?

I am also interested in the same question. Please comment on how is this different from Relativity.
For a number of reasons I would like to find a better alternative to Relativity and I would like to know the difference.

Some questions:
- Does Node Hierarchy provide Views-integration?
- Can you enforce referential integrity, i.e. delete child nodes when parent is deleted and don't allow for orphans to be created (without a parent)
- Does Node Hierarchy provide some blocks/views to make the display of children/parents more configurable?

Thanks!

node family is other module that allows hierarchycal relations between nodes types, what advantage provides de use of node hierarchy when compared with node family?.
Also, node family is required by node profile, i´ve used this last one and plan to use it on future projects, the question is: could it in anyway conflict with node hierarchy?

i didn´t know the Relativity module, i´m downloading it right know to try it, i believe the questions above go for this module as well.

in conclution:
WHICH IS BEST? NODE FAMILY, NODE HIERARCHY, OR RELATIVITY?

Actually I tried this module tonight and I can say that it is GREAT! Thank you!

This is exactly what I needed!

I have a few questions about it's usage but I'll post a separate support request for this.

The book module is also similar. One of the few things the book module does is to add a column with a parent nid of any node, so that a table of content (TOC) and links to next/previous page can be automatically generated.

What I really miss, is a module that not only defines parent/child relationships, but also defines what kind of relationship which exist between the two nodes. This will make Drupal able to be easier interoperable with RDF-based solutions.

Do anyone know any Drupal projects that address this semantic node relations problem?

The node relativity module seems to me more active & supported.

Amnon
_{-
Professional: Drupal Israel | Drupal Development & Consulting | Eco-Healing | Effective Hosting Strategies | בניית אתרים
Personal: Hitech Dolphin: Regain Simple Joy :)}

Keep the information coming please! I too am trying to figure out which of these modules (family, relativity, hierarchy) is "best" at least for my use.

Among other things, I want to create a simple "contact management" system. That means there are "clients" who are typically companies, with a name, address, etc. Each client has one or more "contacts" who are people who work there, and "contact history" which is a history of communication with an individual contact, but also needs to be visible as a history of communication with the client.

At the moment I'm playing with "node relativity" - It seems to work well, and automates some of the process, automatically setting up links for adding (in my case) new contacts for clients to the view page of the "client" node. I'd like more configurability as to the titles used for those links, maybe ability to add a short help/description text etc. But, for prototyping the auto-generated stuff is fine. You can configure views to list (e.g.) the contacts for a client on the client-view node, though so far I haven't figured out what the filters need to be in order to show only the correct subset.

So, I'm using "relativity" as it speeds up prototyping. But I think it might actually slow down the overall process, as in the long run I'll have to replace a lot of the auto-generated stuff with my own views.

In general, am I right in thinking that the functionality all of these modules could be duplicated using Views and "node reference" fields?

Can anyone give a more complete comparison of these three modules and any other options? Thanks.

P.S. I am relatively new to Drupal, so please excuse me if I'm stating the obvious or asking dumb questions!

Hi,

I feel bad adding to the already confusing landscape of drupal contrib by contributing a module which duplicates existing functionality. I am further remiss for not addressing this issue until now.

Basically, from what I can tell, nodehierarchy and node relativity accomplish more or less the same thing in slightly different ways. Node family seems to be somewhat more abstract.

I wrote this module in late 2006 as a way to get a simple (emphasis on simple) way to maintain menus, breadcrumbs and urls in a hierarchical way without hand managing. I had used the 'Category' module previously and found it unwieldy and heavy handed. That's what I wanted to avoid with nodehierarchy. In retrospect, it would have been better for me to have tried to use node relativity rather than roll my own solution. In fact, the reason I didn't release this module for almost a year after I first built it, is because I didn't want to add 'yet another module' solving an already solved problem. I eventually did release it, because we used it when we built the Rake Magazine website, and we wanted to list all of the used modules in the writeup (http://drupal.org/node/191608) and I didn't want to seem like we were holding anything back.

Ultimately it might be better for me to provide an upgrade path from node hierarchy to node relativity and either contribute patches for the functionality differences to that project or provide an addon support module.

For now, I guess anybody interested in both modules should go with whichever one feels right to them. I'm no expert on node relativity so I can't personally make any recommendations.

Among other things, I want to create a simple "contact management" system. That means there are "clients" who are typically companies, with a name, address, etc. Each client has one or more "contacts" who are people who work there, and "contact history" which is a history of communication with an individual contact, but also needs to be visible as a history of communication with the client.

I'm actually working on something very similar for my company... sort of a stripped down crm.

In general, am I right in thinking that the functionality all of these modules could be duplicated using Views and "node reference" fields?

Essentially yes, however, if the structure your site is truly hierarchical it can be easier to use a module like this one to manage it. I have found though that if you find yourself trying to force a hierarchical structure onto your data in order to use this module, you might be better off using a more manual solution with node reference and views.

So, I see there's a new release of nodehierarchy with a few new features - http://drupal.org/node/234793 - now promising integration with various other modules which should be a good thing. I will check it out.

I don't think you should be too concerned about "duplicating" functionality in other modules - sometimes that's the best way for progress to be made.

Re. CRM - Back in the 90s, in the UK, I designed and developed an early CRM system (originally DOS based, then Windows) - yes, I'm that old :) It was the base product of a company that survived for some 14 years before being taken over by a competitor. So, I have the data model and processes for that system very well defined - it worked well, so I am aim to duplicate it in Drupal. I was hoping to do everything with off-the-shelf modules but I'm beginning to wonder if I'll end up doing some coding too.

As has been said earlier by h@r@ld -- there's a need to be able to define how data types relate to other data types. I'd love to see a module that allowed you to set up a kind of data dictionary, naming key fields in each table (content-type) and defining their relationship to other content-types. Apart from anything else, using the views editors and cck systems gets very unwieldy (huge lists of fields) very quickly.

Why not simply work by field name? If the "clients" content-type has a cck field called "client_id" and the "contacts" type also has a "client_id" field, then automatically creating logic for "view all contacts for this client" and "add new contact for this client" should be straightforward? Working by node-reference only may be limiting I suspect.

I wrote this module in late 2006 as a way to get a simple (emphasis on simple) way to maintain menus, breadcrumbs and urls in a hierarchical way without hand managing. I had used the 'Category' module previously and found it unwieldy and heavy handed.

Would you please elaborate what you were able to accomlish easily that can NOT be done with built in taxonomy? Typically people tend to look for category when they couldn't easily use taxonomy. But there is usually a way. So I am wondering if what you achived could have done with basic taxonomy?

Would please elaborate what you were able to accomlish easily that can NOT be done with built in taxonomy? Typically people tend to look far category when they couldn't easily use taxonomy. But there is usually a way. So I am wondering if what you achived could have done with basic taxonomy?

Taxonomy is great for tagging items, but I find if you try to use it to create your site structure, you're pushing it beyond it's comfortable limits. Taxonomy can be used for just about any structure, but that doesn't mean it should.

Keeping your menus, urls and breadcrumbs in sync with taxonomy is clumsy at best, and the fact that taxonomy terms aren't nodes limits what you can do to display them.

I built this site (http://takingcharge.csh.umn.edu/) using taxonomy to create the hierarchical structure, but for the client, creating a new section or article meant editing a vocabulary, creating a node and hand creating a menu item. It was not a huge issue, but it was unnecessarily awkward. I felt they should be simply able to place an article or section in the appropriate spot and have the rest happen automatically.

Just an anser to you, who is creating a crm for Drupal. Looks like you are doing exactly the same thing than I just have been through. I ended up with civiCRM an open source CRM solution that builds on top of drupal or joomla. I build it on top of drupal and it works very well. It does all you would expect from a crm and more but not to the point of being complicated. Most importanty its fully OPEN SOURCE, well documents (IMHO) and was easy to customize. It is aligned for non profit orgs primarily as you will see but I found no problem arranging my own categories and made it to support commercial business just fine. Just to let you know.

leancode: thanks for the input. I want to be careful not to let this thread become a discussion of how to build a CRM in drupal. We should continue this discussion in the forum if we want to discuss it further.

Back on topic:
I'd like to hear people's opinion in this thread on the relative merits of nodhierarchy vs node relativity, and whether I should be working to obsolete my module in favor of that one (with an upgrade path for data of course)

Some quick observations, about which I am more than likely wrong at least once:

Node Hierarchy seems to be much better at managing hierarchies at the tree level. So far as I can tell Node Relativity really lacks any kind of decent interface for viewing and traversing your hierarchy. To this end, Node Hierarchy's outline shines and it's menu creation also allows one to use any menu module (such as dhtml menu) to supply a quickly traversable-tree block. Further to this, Node Hierarchy has built in node weighting to allow re-ordering of nodes in the tree at a given depth, which Node Relativity doesn't seem to do.

On the other hand, Node Relativity allows for nodes to be re-used across hierarchy trees, such that a node can have multiple parents. It also gives links for removing nodes from the tree without deleting them, and a function for reparenting that effectively allows a link to be built to reparent a node. In addition, node relativity supplies useful blocks for viewing some of the hierarchy properties and operations of a node. In other words, Node Relativity seems to provide greater flexibility for creating hierarchies at the node level, and could possibly allow for more complex hierarchies to be built.

To me these seemed to be the main differences. The outliner is what signs the deal for me, as I usually tend to want to manage my content in a top down rather than bottom up approach.

I am a Drupal newbie (a few weeks) and have been trying out both modules to create a hierarchical photo gallery. I am still exploring (Drupal has quite a steep learning curve, even for a software professional!) and discovering some excellent modules like this one.

I am currently leaning towards Node Hierarchy because I can easily embed a customized View of the child nodes in the parent node and I don't like the way Node Relativity embeds children and operations in the Node View (although I could look at overiding this with theming I guess). My aim is to minimize the amount of work/code I need to produce to get the desired effect and Node Hierarchy looks the closest to my requirements at the moment (I don't need multi-parenting) although I don't want authors to have to select the embedded View type (I only need one child view type per parent type). Node Hierarchy also seems to have much better breadcrumb support and the Site Outline is awesome!

I'll post back when I finally make up my mind!

Thanks for your comments CoolDreamZ. Keep me posted on your findings.

although I don't want authors to have to select the embedded View type

Default embedded views is definitely on the docket for nh 2.

Good Luck

Very much subscribing, needing a way to handle hierarchy the easiest way.

Taxonomy terms have allready hierarchy when you choose parent-child relation.
Why shouldn't that not be enough to get hierarchy working?

greetings, Martijn

In the last days support for node relativity in drupal 6 has been removed. I am not sure whether this means that the module dies or whether the maintainer just at present does not have enough time to maintain the drupal 6 version and therefore does not want to get any support requests.

I have looked at node hierarchy and node relativity.

Node Relativity:
node relativity has the ability to:
define a specific parent <-> child relationship. So an event type is parent and the only child type might be organizer. Only organizer would should show up regardless of how many other children types there are in the system.

children can have multiple parents. I am not sure if node hierarchy can do this. So if the organizer I entered for the above event can also be a child of another node type. This is great if i don't want to re-enter information.

Node Hierarchy:
Node hierarchy looks like it will be ported to 6 and it has wide integration with other modules which means a great deal.
I did not see the account settings for node relativity (I looked under node relativity and relativity and nothing was there).
I would help pay a bounty for the additional issues outlined above to be incorporated into node hierarchy.

Also, if I allow additional nodes to be added from a list of already created nodes I want to be able to restrict what can be added to the those items created by the author of the node or not. This is an access setting I think.

I just heard that support for node relativity in drupal 6 was not removed. They just removed an early version because it was not stable yet. So, at some point this module will resurface for Drupal 6 again.

Uersu: changing the title for you comment changes the title of the whole thread.

And it's not "at some point," Node Relativity has a dev release for Drupal 6 right now.