Node Relativity 3.0

By wilco on 19 Sep 2008 at 21:20 UTC

To the multitude of Node Relativity fans, users and developers out there!

We are moving into a new version of Node Relativity and as such, we wish to feel out what everyone has to say about where they might like to see this module go.

I propose we use this forum to begin a wishlist of features and functions the next iteration of Node Relativity should, could and may incorporate.

As many of us currently use this module with Drupal 5.x, this next version will first come out for D5. Once we've moved it into a Release Candidate version, we'll begin a porting of the code to D6.

In the interim, those wishing to use Node Relativity with D6, please take advantage of the work already put into the DEV edition relativity-6.x-1.x-dev.tar.gz

N.B.: Both D5 and D6 versions will be synchronized version numbers.

It would be nice to keep this forum down to bulleted lists of features such that we may compile lists easily and provide feedback without having to read Essay Answers. Therefore, I request that you keep your answers short and sweet.

Concise and to the point, friends.

Thank you and good luck to us all!

Comments

Wishlist Items

wilco commented 4 October 2008 at 13:45

Preset driven relationship definitions: I really like the Imagecahe and User Relationship module use of presets. I believe we could do the same for this module

Taxonomy-like API: After reviewing much of the taxonomy engine in Drupal, I've come to the conclusion, relationships between nodes should have the same power and flexibility that are given to categories. The various contributed projects provide in some fashion an interpretation of the taxonomy functions, yet the flexibility of easily defining these relationships lacks in most implementations. This will be closely tied to Preset driven relationship definitions.

Refined Access Controls: I've noticed a serious lack of permission granularity in the module, thus exposing a greater set access controls to roles would be nice.

More theme function flexibility: In the previous versions, theme functions were very heavy and required a high degree of PHP understanding to get the module to do what should be simple. By simplifying the theme functions, exposing API calls and increasing the Administrative Front End display features, we could greatly enhance the theme flexibility of the module.

Improved VIEWS integration: I believe we can provide better filtering and sorting criteria for the module. I propose that each relationship preset have a multi-select option permitting the administrator to select which fields from the parent's node will be exposed to VIEWS.

Improved CCK integration: Much like the node_reference CCK type, this module should not only expose node operations to the viewer of the node relationship, but also to the editor. Thereby increasing the flexibility and power of the module. Attaching and detaching relationships between nodes should be simple and painless. Also, providing easy filtering of node lists for parent/child selection should be flexible enough to be done from within the node edit form.

More robust pathing/menu handling routines: I've come across some pretty horrible URL based path issues that can quickly expose Node Relativity to abuse. These holes need to be plugged and naming conventions need to be easily modified by the admin (think PathAuto and Token modules)

Better Breadcrumbs: Given the number of times we've seen this issue come up, it is paramount this module provide a mechanism to expose breadcrumb options, easily and simply to the administrator of a relationship preset.

_______________________________________________________
william roboly - openject consulting - openject.com

_______________________________________________________
william roboly - tribus.studio

Wonderful!

Mac Clemmens commented 6 October 2008 at 05:08

I'm very glad you are tackling this!

Integrating access controls at the node level, and then having the permissions move recursively down the node tree is a very powerful feature. (currently made possible through the relativity_access module). I asked chx to help me work on this and we have an improved version, which uses some of the code for the D6 menu system to optimize the queries. The limitation is 10 levels of the hierarchy.

OK -- and the big feature I would be willing to chip in to help to create would be -- AJAX drag and drop handling of nodes and branches, just like the menu system and the category system (maybe even using the same code). That would make this module really a breakthrough for some of our non-profits partners that use Drupal as an online database.

Ajax/Ahah interface

pkej commented 2 November 2008 at 10:37

Ajax/Ahah interface
Take a look at Taxonomy Manager and Term Relation Types, those two modules makes it very easy to manage relationships.

For Relativity 3.0 I would like a similar system available for the administrator, but in addition for day to day use there should be a local task (tab) in the node edit to select from a list of possible targets (much like relativity today) from a popup, and of course a possibility of creating new targets if the needed isn't made yet.

The same system could be utilised in the node, if you browse a node you can add relationships to it from the same api.

That's mostly the same as Improved CCK integration

Implied nodes and Implied Relationships
I almost wrote implied relationships, that might be nice, but not what I mean. I often come across situations where I need a node that I really don't want to add manually.

For example, a quote can have different types of sources. For example a quote could be from Time magazine. A magazine is a periodical with pages, so I need to indicate which year, month and page the quote is from. The year, month and page data is not relevant for the quote node, nor for the Magazine node.

Neither is the page data relevant to the year and month (and date for a newspaper).

Therefore the modelled system would be:

Periodical must have Editions
Edition must have Articles
Articles can have Pages
Articles can have Quotes
Pages can have Quotes

But, we also have books which can be quoted, those would be like this:

Book must have Pages
Page can have Quotes
Book can have Quotes

Thus the user who is inputting a quote would be presented with a quote form:

Quote: The individual feels the futility of human desires and aims and the sublimity and marvelous order which reveal themselves both in nature and in the world of thought
Source: Religion and Science

The source doesn't exist, but we are using Relations 3.0 so the hooks in R3-0 (ar-three-o) have hooked into the node save form, detects we have a quote, and it lists up all the source types in the next form (or in a pop-up ahah form):

Magazine Article
Book
Essay
Letter
Speach

And the user selects Magazine Article. Then the next form will ask for the following:

Magazine: New York Times Magazine
Date: November 9, 1930
Article: Religion and Science
Page: (is left blank).

The rules we have defined then sets in and creates the following nodes:

Quote
Magazine
Edition
Article

And links them according to the rules. That is the Implied Nodes.

In the view of Quote we can see the following:

This is the Implied Relationships, plus a new field display I just thought of a Comma Separation for Field Groups, which would take and comma separate all the fields in a group. In actuality it would look like this:

Quote: The individual feels the futility of human desires and aims and the sublimity and marvelous order which reveal themselves both in nature and in the world of thought
Magazine: New York Times Magazine
Edition: November 9, 1930
Article: Religion and Science

The Implied Relationships are Magazine and Article. The fields can are like noderferrer fields, you can decide to display them or not.

Another example of Implied Relationships is a project I'm working on now. I have Building, Floor, Apartment, Room, Fuse Box, Fuse, Fire Loop, Fire Detector, it is a management system for a hotell/apartment rental company.

Lets look at the Fire Detector. It belongs to a Fire Loop, together they form an adress assigned to a Room, the Room is in an Apartment, the Apartment, is on a Floor which is in a Building.

The Building has an address and access instructions. When the fire alarm lits up on a location, I want to use a search form which asks for which detector and which loop the alarm occured on. And based on those two values I can get the building address, the floor, the apartment and the room in which the alarm was set off.

Or if a resident is calling, I can punch in her name and have her apartment on the screen (with the drawings) and then just ask which room the power is off in. I then can get up the information about the fuse and where the fuse box is located, I can logg this to the room and go and fetch the right fuse/or reset the auto fuse.

The logg, of course propagates to the building level, so I can see the logging ticket both on the building view, the apartment view, room view and customer view. Those are all Implied Relationships

Paul K Egell-Johnsen

A bit advanced

pkej commented 2 November 2008 at 10:47

Of course this is really complicated stuff, but I've been thinking through this in pseudo code, and since Drupal have all the hooks needed, it can be broken down to quite managable parts.

Nothing of this requires any fancy SQL, of course we need to store the implied nodes (in creation order) and implied relationships in their own tables, but, the save, alter and delete hooks of nodes will do the checking, and updating the relevant fields and database tables.

There shouldn't have to be any more lookups than with nodereferrer (for the implied relationships rendering in node) for node view.

Paul K Egell-Johnsen

The Quote Example

pkej commented 2 November 2008 at 10:52

The Quote edit form should be like this:

Quote: The individual feels the futility of human desires and aims and the sublimity and marvelous order which reveal themselves both in nature and in the world of thought
Source Type: Magazine Article, Book, Essay, Letter, Speech (A drop down list)

Then upon selection of source the relevant subform should be fetched through ajax/ahah.

On post the save hook is taken over by R3-0 to create the needed nodes.

Moving a Quote from one Source to another would not delete the old source (no cascading delete triggered when a source looses all its quotes).

Deleting a node wold not trigger a cascading delete.

Paul K Egell-Johnsen

It would also be nice if

jastraat commented 19 September 2008 at 22:38

It would also be nice if there was an upgrade path from the current version.

------------------------------
http://fraggles.artsci.wustl.edu (Drupal user documentation and development blog)

link operations

Daryljames commented 21 September 2008 at 23:25

I think it would be awesome to expose link operations to views also... not just as a block but as a field in views...

Great ideas!

wilco commented 14 October 2008 at 20:52

That's a really good idea, though, frankly, since the relativity operations are theme_hooks() you can do that easily from a tpl file... seems almost redundant. Though, I can see the value of having the operations easily added via the front end. So, duely noted and put on the wishlist.
_______________________________________________________
william roboly - openject consulting - openject.com

_______________________________________________________
william roboly - tribus.studio

Link operations controlled by Book module

dafreak commented 20 February 2009 at 12:54

I've been looking at the link operations. I wanted to modify and/or get rid of the links on my "mother" page (top level page to which others are children). I tried working with CCK, Contemplate and Views, but just couldn't figure it out. Where the eff are these links coming from? Well I found it. Using Devel and Firebug and other such diagnostic schtuff, I found that the Book module treats any content types with parent/child relationships as a Book. Book automatically creates the table of contents and breadcrumb, and next, previous, and up links.

I was able to modify the line in Book and get rid of the links. I'm working on getting modified links going or maybe a separate module to control the linking systems.

Will come back with an update or to see if anyone has good suggestions.

Cheers,

Freak-Out

Token for parent bookpath + breadcrumb

merilainen commented 22 September 2008 at 13:24

It would be nice if there was a token like [parent-book-path] available, if the parent is type of book. Also an option to show this parent in breadcrumb would be useful, otherwise connection to parent item is lost easily when user is taken away from the book navigation. Maybe book navigation should also stay visible if showing a blog entry related to a book page.

Nice to see this module

sdecabooter commented 24 September 2008 at 09:25

Nice to see this module moving on!

My wishlist consists of better integration with Views, Token support, better differentiation between the API & UI (perhaps split up?)

I wonder though if it wouldn't be better to start the 3.0 work on this module for Drupal 6, and then backport to Drupal 5? Given the new Views 2 and other nice new things in Drupal 6, I think it would be more interesting to step forward when creating a new version of this module, while still supporting (most of) the new features in the previous (D5) version ...

By the way: wouldn't it be easier to create a group for this on groups.drupal.org, rather than relying on 1 forum thread? This would allow for simultaneous discussions, while you could still have a short & to the point wish list thread...

If time permits, I'd like to help out with this module, although i'd like to focus more on D6 personally...

I agree with a move to D6 as

mrfelton commented 1 October 2008 at 13:00

I agree with a move to D6 as a priority. D6 is already begining to gain widespread usage and developing modules for D5 is only slowing the upgrade path. People are still in need of a reason to upgrade - let this module add to the long list of existing reasons :)

--
Tom
codegobbler.com - web design and development

--
Tom
www.systemseed.com - drupal development. drupal training. drupal support.

I concur

wilco commented 1 October 2008 at 19:47

I've taken in the comments and thoughts for a move to initially bring this module out for D6 and then backport it.

I believe it is in the best interests of the community, so we'll go with that!

Thanks for your thoughts and support.

_______________________________________________________
william roboly - openject consulting - openject.com

_______________________________________________________
william roboly - tribus.studio

I know this is probably a

mrfelton commented 3 October 2008 at 11:42

I know this is probably a question that you don't wat to be asked... but what kind of timeframe do you think we are looking at before we could have a usable D6 version?

--
Tom
codegobbler.com - web design and development

--
Tom
www.systemseed.com - drupal development. drupal training. drupal support.

Another module

bomarmonk commented 4 October 2008 at 04:56

I just saw that in addition to node-heirarchy, there is also the Node-to-node module: http://drupal.org/project/node2node

Should efforts be combined here?

Two answers for the price of one

wilco commented 4 October 2008 at 13:21

With respect to timeframes, I hope to have an alpha by the end of the month of October. As I have been reviewing the tickets for the project, I've also been evaluating the node2node, node_hierarchy and node_relativity module for inspiration.

I should have a plan of action ready to be digested by the community within a week.
_______________________________________________________
william roboly - openject consulting - openject.com

_______________________________________________________
william roboly - tribus.studio

Hi, you mentioned that we

Flying Drupalist commented 4 October 2008 at 22:00

Hi, you mentioned that we should try the dev of 6.x as well as an alpha by the end of the month. So is the 6.x dev really usable, being pre-alpha? Or do you mean 3.0 alpha and 6.x -1.x dev is a working port of 5.2?

Or something entirely? I'm really anticipating the 6 release of this module. Good luck, I'll be cheering.

Group coming soon!

wilco commented 5 October 2008 at 00:35

To answer your question, I should clarify what is going on.

I am not maintaining the previous editions of Node Relativity. My interest is in moving the module forward. I've used it extensively with D5 and loved it from the onset. The tragedy of the module is I've had to modify it extensively to solve what I've felt were inherently obvious issues. This is not a hit on darius' hard work, quite the contrary. I admire his work and diligence.

As with all development, the seeds of a good idea begin in the ground and flourish with the contributions of others.
Therefore, I am branching the D6 version I am developing.

It goes like this:

DRUPAL-6--1: darius edition
DRUPAL-6--3: wilco edition

I know, it's maddening to have this kind of progress happening now. But I do not wish to step on darius' toes with his release; which looks to be a port of the D5 version into D6.

My version is a complete re-write of the module.

Since this could become a serious issue to contend with, I will open a group shortly for this, so we may begin discussing the various issues relating to relativity without too much comment-thread confusion.

_______________________________________________________
william roboly - openject consulting - openject.com

_______________________________________________________
william roboly - tribus.studio

Thank you very much for your

Flying Drupalist commented 5 October 2008 at 03:37

Thank you very much for your clarification.

tt

hansvirus commented 6 October 2008 at 05:14

Also, will you include an

Flying Drupalist commented 5 October 2008 at 05:58

Also, will you include an upgrade path from 6.1 to 6.3?

First Pass

wilco commented 5 October 2008 at 15:39

With the initial version of the new module, I'll attempt to get things to work first. Once we have that working, we'll look at what we can do about moving legacy relativity settings into the new edition.
_______________________________________________________
william roboly - openject consulting - openject.com

_______________________________________________________
william roboly - tribus.studio

Another General Question

bomarmonk commented 5 October 2008 at 16:23

I am just trying to wrap my head around relational nodes in Drupal (outside of books), so hopefully the answer to my question isn't too obvious. I was wondering if your version of node relativity will be compatible with node reference in CCK? There are various extensions for node reference, including node referrer and "node referrer create" which allow you to add child nodes to parents. However, the functionality of this is somewhat limited (at first glance). But I do like the idea of a flexible CCK widget that allows the selecting and adding of related nodes (or even creating related nodes within the node edit form or when viewing the node. Sorry if this is a bit outside the range of this discussion, but your plans sound fantastic for node relativity! Thanks for your plans and work on this!

Check out the Handbook

wilco commented 11 October 2008 at 06:01

I've prepared a book where I will be highlighting and annotating the new Relativity modules functions and instructions.

The handbook.
_______________________________________________________
william roboly - openject consulting - openject.com

_______________________________________________________
william roboly - tribus.studio

Additional feature

enzipher commented 13 October 2008 at 14:31

Great to see this module develop! I don't know if it has been discussed or not, but I made a post some time ago to which I am still looking for an answer. I think it would be a nice feature in NR3.0.

Here it is: #270280: Possibility to specify in which way parent and child relates

_{_{--

hook_world() is broken.}}

Right on target

wilco commented 14 October 2008 at 20:54

You'll note the very first item in the wishlist Preset driven relationship definitions is exactly that.
_______________________________________________________
william roboly - openject consulting - openject.com

_______________________________________________________
william roboly - tribus.studio

Absolutely wonderful!

enzipher commented 14 October 2008 at 23:46

Will there be any possibility to have multiple "Preset driven relationship definitions" as well (as shown in my nice ascii drawing)?

_{_{--

hook_world() is broken.}}

Our proposed functionality

wilco commented 16 October 2008 at 02:43

Much like the Imagecache module, relationships will be defined by sets of filters. Each set or preset will be composed of filters which are defined as criteria expressing the relationship (or connection) between content types. In essence, this provides a simple meta-language which can be used in conjunction with either relativity API calls or Views to manage the display of content to the user.

You know, the fun stuff! :-)
_______________________________________________________
william roboly - openject consulting - openject.com

_______________________________________________________
william roboly - tribus.studio

Can you create sibling

Flying Drupalist commented 13 October 2008 at 20:40

Can you create sibling relationship between nodes? And easy nav to and fro based on that relationship.

Ahh well I discovered that

Flying Drupalist commented 14 October 2008 at 02:02

Ahh well I discovered that 6.1 doesn't actually work, or is bugged. The children/parents node don't show up correctly. You're not working on that at all right?

I can't wait for 6.3 then.

Alpha Alpha!

wilco commented 14 October 2008 at 20:59

I've been doing some pretty nice in-roads on the module, so I'll try to get a pre-alpha (that's funny) out by the end of the week!
_______________________________________________________
william roboly - openject consulting - openject.com

_______________________________________________________
william roboly - tribus.studio

subscribing

mcreature commented 19 December 2008 at 19:25

mcreature subscribing

subscribing

mcreature commented 19 December 2008 at 19:29

mcreature subscribing

Full node/teaser display settings

jjalocha commented 27 May 2009 at 12:51

I think, I couldn't see these in the proposals so far:

Please make it possible to set different options for full node and teaser display. This distinction is commonly made in almost all Drupal modules. (A rather confusing feature request has been made quite a long time ago.)
A slightly similar request has popped up in another post: "it would be nice to be able to change the 'child' & 'parent' labels on a per 'content type' basis".

Infinite Loop & WSOD.

stevegmag commented 14 July 2009 at 16:26

I've been using this module (D5) for a while now for one-way Parent-Child relationships between pages and stories.

I just created a sibling or recursive relationship A->B & B->A and I'm getting and infinite loop as A->B then wants to include B->A from the B node and so on.

This also happens if I expand the loop like A->B->C->D->A

This type of relationship kills all the pages in the circle.

Getting Errors: [notice] child pid 71061 exit signal Illegal instruction (4)

Is this something I'm doing (beyond the relationship building) or not doing or an issue/limitation or the module? If there something I can do to only so the relationships one child deep?

Attach more than one child at a time

cspbm commented 9 December 2009 at 14:39

Is it possible with the current 6 version of with the dev version to attach more than one child at a time via a multi-select option? This would be greatly beneficial.

Thanks