Robert, You are correct that my goal is to use this and other existing drupal modules to make complex models. The possible types of relationships are between parent and child of each combination of node type with the ordinality of each relationship specified (in both directions) as well. Visually representing the connected nodes hasn't been addressed very much yet (currently just linked node titles) and thoughts on the subject are appreciated. I'm using this to glue a bunch of mostly flexinode nodes together as metadata to identify event logs of another application. The one non-flexinode node essentially glues all of the other pieces together, and it's nid gets propagated into another system. I use a connected node query (several, actually) to find all nodes related to this one and populate a metadata reporting table from that. This table will have a column for each node type in the system as well as a unique identifier for each specific event type, a timestamp and several "roll-up" columns of the previous period's data. There will be a reporting interface on top of this table that will let me navigate the report in a hierarchical way. I'm going to use the structure of the connected nodes to direct the reporting "data cube" view. I couldn't really see how to do that with the existing set of drupal features at the time. Also, my set of metadata types (now up to 19 node types) seems to change everytime a client gets a new idea or some nifty whatnot comes out that needs to be tracked and reported on. I just add another flexinode to the system somewhere, another table column, and it shows up on the reports. That's the plan, anyways, I'm still working on it :) Andre, I have all of the basic functionality implemented in the CVS HEAD version as of this afternoon (gmt-6). Please give it a run. I'm particularly happy with how the query tool is coming along. -Mark Robert Douglass wrote:
I think the goal is to have views that are composed of more than one node. This is something Drupal doesn't support in any way, really, at this point. The best you can do is either use a filter to spit some output into the body of a node, in which case both nodes are unaware of the association, or attach a node to another which ususally takes the form of lumping their combined output onto one page.
As I understand it, Mark is writing a module where you can make complex n level relations between nodes. This will help us move away from Drupal's almost exclusive web-publishing content-oriented features (blogs, books, pages, stories, articles) and approach the needs of the web-application developer who models data and relationships, collects that data, and presents it in different views.
I'll take an example from Gavin King's Hibernate book. There he models Cats. Cats can have relationships to other Cats. In fact, they can have three types of relationship; parent-child, rival, mate. When objects (nodes) are aware of their relationships you can do queries. You can then say, "give me all Cats who are rivals of this Cat", or "give me all Cats who are mates of this Cat's rivals", or "give me all Cats who have no mate".
You can also have complex views. When showing a Cat, you not only show it's information (name, age, color), but also what it's relationships are. In the best case you can theme these as you wish. Perhaps you want hyperlinks to their pages, or perhaps you just want to display thier name and color. In any case, from the context of Cat X, you can access the information of Cat Z just because the two of them are joined by a relationship.
Not that Mark's module is going to be able to do all this right off, but I think this is the type of functionality he is dreaming of.
-Robert
Andre Molnar wrote:
Mark, this may seem like a very silly question, but what will your module do that book.module doesn't do - or what doesn't book.module do that you need?
andre