[drupal-devel] Working around node_access in node/add

Mark mark at nullcraft.org
Fri Feb 11 23:43:10 UTC 2005


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 :)

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.


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

More information about the drupal-devel mailing list