Big (node relationship) questions for a high profile project -- to go w/ Drupal or to not?

Hi Dave,

I work with Sid, and I wanted to take a moment to give you some more info based on my experience with the project we're working on together.

The Views module is extremely powerful. Get to know it well. It's perfect for querying nodes based on various properties, and then displaying the matching nodes. In addition to having a view as your page or in a block, you can have code that puts a view pretty much anywhere. You can also customize how you theme the view. And with a little more in-depth coding, you can add plugins to the view module if you want to query based on criteria that there isn't a plugin for already.

Get to know CCK well. When you make a node using CCK, all of its fields are automically available as selection criteria for a view (assuming you're using field types that are properly implemented). CCK also includes a node reference field type, which can be used for setting up node to node relationships, although there's pros and cons to that approach (pro is that it's easy, con is that the reference can be orphaned when the target node is deleted).

Get to know the Category module. It lets you use nodes instead of taxonomy terms for categorizing other nodes. A lot of relationships can be represented as a "A categorizes B" relationship, and this module is perfect for those. It can also be used for creating "A is a parent of B" relationships, since category trees can be heirarchical.

Node Relativity is a great module. It lets you create generic "A to B" relationships between nodes. In theory, this can be used for "A is a parent of B" relationships where you don't want to make A or B into categories, although I prefer to use it for associative relationships rather than structural relationships. For example, "related articles" or "related documents". I like the UI this module uses for setting up the relationships.

There's also the Relationship module. I haven't worked with it yet, but I like what it says in its description -- that it has an extensible mechanism for specifying what kind of relationship you're creating when you associate A and B.

Node Family is good if the relationship is based on node type rather than individual node. Although, if that's what you want, it's pretty easy to do with views instead. It also lets you restrict how many nodes of a particular type can be created by any one user, and that's pretty cool.

There's a great discussion here (http://groups.drupal.org/node/1323) about the issue of node to node relationships.

Hope this helps,
Alex.

Hi Dave,

Alex and I talked this over. Here's what we came up with.

Our sense is that Drupal provides almost all of the functionality that you describe. Yes, it will definitely take some amount of custom coding to make it solve your specific needs, but most of it is already there. So, unless the already built pieces available to you also do most of what you need, we'd bet that you'll be able to build a successful site more quickly, and thus less expensively, using drupal as opposed to rolling your own. (We return to these questions in our final paragraph.)

This sounds like a pretty complicated project. Much as we'd like to, we can't really do a complete analysis and design on the forums. To do an adequate job, we'd need to understand quite a bit more about what we are trying to model.

Roughly speaking we would see a process working like this:

1) Analysis Phase: Understand what the objects in the system are, determining what node types and nodes we need, and the relationships that need to exist among them. I appreciate that you've taken a stab at outlining this, but we'd need to understand a good deal more before we could really answer these questions.

During this phase we would ask questions such as the following. Are the relationships many to many or many to 1? Can the same role be associated with multiple proposals? If so, when an asset is associated with a role, is it always specific to the proposal, or can it be associated to the role in general, regardless of proposal? Depending on the answers to these types of questions, it will become clearer which specific modules to use for building the relationships.

2) Design: determine what content types to build with CCK, and what fields those types have. Determine what views are needed. Determine what modules to use build the relationships we need (see Alex's previous post on the various modules that are useful for relationships).

Once a complete A&D was done, it would be rather straightforward to actually build the system.

The key concept I think is the theming work that goes on between the CCK and sending a page to the browser. That theming work can involve running any number of views to gather the needed information, and then to format its output as necessary.

Just to take one of your examples: "Proposal detail page. Show proposal detail here, show top roles here, show this associated asset there, show comments on this proposal (including on sub roles and assets)." Quite likely there would be a proposal node type with a node for each proposal. When a user went to that node, the theming function would do something like the following:

1) Run a view to gather all roles associated with the proposal that met the criteria for being considered a top role.

2) Run a view to gather the relevant information about associated assets.

3) If comments are Drupal built-in comments, run a database query to collect the needed ones. If they are custom nodes, then run one or more views to gather the needed ones.

We would already have the information for the proposal node, which would likely include the details for the proposal. If it didn't, we'd use another view to gather them.

Once we had all this information, it would be very straightforward to output it as html.

Finally, CSS would be used to fine tune the look and feel as needed.

Needless to say, there'd also have to be a whole set of interfaces for creating entities (such as users, proposals, assets, roles and comments) and relationships among them. The nice thing about CCK is it already does most of the basic work involved in creating admin interfaces.

Everything you've outlined is possible. But depending on the specifics, it could be more or less work. Our sense is that it will be much easier to start with Drupal and build the custom stuff than to build the whole thing from scratch. But we say that as folks who have a lot of Drupal experience. For someone without enough Drupal experience, it might be easier to not have to figure out the "drupal way" of doing things.

Would this be available in d5.x, when?

- M

Still looking for a solution here. I need a sibling-sibling relationship not really a top-down relationship.

I have a patient node type that might have multiple research study nodes associated with it. The patient also might have multiple status nodes associated with it. I need to be able to draw a relationship between one of the patient's studies and one of the patient's statuses. Just in case this isn't clear I'll give an example. Patient A is enrolled in a Diabetes Study and his status for that study is "qualified", while his status for an asthma study that he participated in last year was "disqualified".

I could create another intermediary node to manage the relationships but that just seems messy. Is there any way to easily build in these relationships with CCK or another module like Node Family?

Ideas?