I'm still plowing through this application, and I've come across one of those decision points whether to write my code in a custom module or integrate it into the relativity module. I solicit opinions here for resolution.

I need to be able to restrict the list of possible children for a given node type to only the ones who share a common child. An example of this:

A  C D     E G
 \ / /      \/
   B         F

If C,D, E and G are all the same type and A may have a child of this type, I want to restrict the list of possible children of this type to C and D, as they share a specific node child with A.

Here's my dilemma: I could perform a query to list out possible children and programatically establish the relationship, or I can add yet another feature to relativity module that will further complicate the admin settings page. I don't even know off hand what the further complications would look like, but with 20-something node types, my relativity settings page is getting very large.

Ideas/Opinions?

Comments

javanaut’s picture

javanaut commented

This is coming along quite clumsily. The UI changes involved are minimal, but the logic for implementing it looks like it will be CPU intensive the way it's heading. I've added a function:

function relativity_list_grand_relatives($node, $rel_type1='child', $rel_type2='child', $conduit_types = NULL, $types = NULL) {}

I'm sure I'll be using this quite a bit.

I'm also coming upon the need to use a stored relativity query to govern a relationship. Yet another feature coming up, and that *should* keep me afloat for a little while longer.

Yes, an "advanced advanced settings" tab seems more and more appropriate.

javanaut’s picture

javanaut commented

Ok, this turned out cleaner than I thought it would.

I've committed the feature to CVS HEAD, but one thing was left undone:
When a required common child is deleted, the relationship loses its integrity. No facilties are provided to unrelate a required child, but it (the node) can be deleted completely (and all of its relationships are deleted to), leaving a structure that violates the rules. I'll look into this soon.

The only appropriate behavior that I can think of is to remove all dependent relationships as well as the common node's relationships. I think I'll do this now :)

javanaut’s picture

javanaut commented

After a little more testing today, I'm changing this to "fixed" for now.

It seems to be working.

Anonymous’s picture

(not verified) commented