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

[Andre Molnar]

Gotcha,

I suppose taxonomy does this to an extent - and Bèr project seems to be 
building on that.

I was just curious about the desired relationship.  Clearly its more 
than just parent child.

I'll be taking a look at this when its done.

andre
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
>>
>>
>>
> 
>