[drupal-devel] Working around node_access in node/add
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
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
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.
> 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?
More information about the drupal-devel