Flexinode relations

This is an interesting idea. I imagine it could be developed as a contributed field type. I'm changing the version on this request; it's unlikely to go in for 4.4 unless someone else provides a beautiful patch.

More description

After talking with JonBob, I plan on implementing this feature using the existing taxonomy.module.

The only place this relation is applicable is a drop-down/multi-valued field. There already is a drop-down field, so I'll start by creating a new drop-down like field that would aim to eventually replace the current implmentation.

There is the steps that I invision the user using this feature.

1) The user creates a new vocabulary that holds the multi-values. He/she then creates a new term that would hold the "multi-values" nodes. In this case, the term would be named "Publishers".

2) The user would then add a new flexinode field called "multi-valued menu". One of the options would be to select a taxonomy term which holds the value nodes.

Notes:

I'm not sure how the field would know what value to display, as the nodes are different types... depending on the implmentation, I might make some assumptions, such as that only other flexinodes are allowed. Probably more specific... like, flexinodes that only contain a single text-field named "description." I would have to somehow discover what values are present depending on the nodetype.

Sorry for the late update...

I don't think I was clear on the kind of relationships you were referring to in the follow-up so I hastily signed up for the job. Allow me to update you on what's going on.

So far, I'm 90% complete in implementing this new "node select menu". I have to pester JonBob to add a new hook for my current implementation that will allow the user to select a vocabulary, but I don't think it's a big deal. Right now the vocabulary nam is hard coded.

Here's my design decision for now and what I've implemented. Hopefully, I'll have a patch by tomorrow. I agree with you that I am aiming for a feature that would allow many-to-many relationships but that wasn't something I would have been able to code in a couple of days and I need a solution by Friday. So I decided to do the most obvious and easy portion of the full feature: one-to-many relationship. Not much but I think sightly more flexible than the current select/drop down field.

Here's how it works so far:

1. The user creates a term to hold the nodes to be used as options.
2. The user adds as many nodes term to be used as select options.
3. The user selects the vocabulary word that contains the terms that this new content type would display. This vocabulary holds all the terms that flexinode can use as values, much like image.module and forum.module
3. When the user clicks on "Add Node Select", a drop down many, much like select menu appears as an option.
4. The user then selects which term in which the nodes used for options reside.
5. Now, when the user clicks to create a new flexinode type, an options is displayed, once again, much like a select menu.
6. When the user views the content of the new flexinode, the node selected as an option is display, linked and ready to be clicked and viewed.

This allows the user to create different terms holding various different nodes. The nodes are then available as options when creating a new flexinode content type. It only cares about nid and title of the node so it doesn't matter what node type you use.

This should probably be considered a hack rather than a sound long range implementation. For now this is what I've done and it should be enough for most problems...

robertDouglass, this solution hides the link, but it now requires an extra click to go to the publisher's link. But if you're using weblink.module, then you can manage those links to the publisher within a taxonomy term and also treat them as first class citizens. I hope this is good enough.

1) When defining a flexinode, the user can decide to which types of nodes the flexinode can make relations, and what kind of relations they are (1:n, n:m).

I agree with you that I'd like to have N:M relationship in the end. But that would require alot more code and definately, it would require a separate table to maintain the relationships. I don't have the time at the moment to write all the code taxonomy.module already does. But taxonomy.module is perfect if where only trying to implement 1:N. This means that you get a list of nodes to choose from when creating a new flexinode with a link to the selected node.

2) Given an instance of a node which can have relations, it should be possible to either choose a related node from the list of existing nodes or create a related new node, whereupon the relation is formed automatically. For example, given a Person node which can have addresses, there should be a button for 'new address' as well as 'link to address'. It would be rather cumbersome to always have to create the address on a different page, go back to the person and then establish the link.

This assume that N:M relation. Let me assure you that I'm hoping to do that soon after I get what I'm current implmenting. For now it's going to have to be clumbersome and force the user to 1) create the necessary address nodes, 2) add them to a term, 3) the link them to the Person node as they create a new person or modify an existing one. We could make it easier by providing a user-friendly GUI but that's another issue.

3) The relations should have names. This will allow us to make queries later, like 'give me all people who are linked to this address'.

Once 1:1 relations are implmented with taxonomy.module, each term would be the name of the relation.

4) Some relations are exclusive. An PhotoID which is linked to a User doesn't show up on the list of available nodes for other Users.

This is for another version. For now, a node can be selected as an option as many time as they want. I think this would be good feature for future versions.

5) User permissions must apply. User who instantiates a flexinode can only link to flexinodes for which he/she has permissions.

This one is a biggy... I didn't think about this one and I'm not sure how this would work but I believe if node_load() uses node_access() I think this should automatically happen. I haven't done any testing and I'll need to ask JonBob or some other person who more knowledgable. I think this should be implmented ASAP though.

6) Default rendering of a relation is a hyperlink to the related node with the text from a standard field (title).

Done.

7) It is possible to define an alternative to the default in 4. Perhaps specify a template which renders the related node and merges the output to the main node, like an include. For example, a Person node can be related to several company nodes. The company node template ouputs the company name, company phone number, but skips the company address. Name and phone number from all linked companies are outputted to the person page and there is no hyperlink to the related nodes.

Interesting idea. No idea how this would work. It would probably be implemented in _format() to determine the template... A more practical solution might be to see if that's something that should be handled by CSS. The linking is another issue I assume.

Last Note:

Okay, html screwed the formatting... here's another try

Sorry for the late update...

I don't think I was clear on the kind of relationships you were referring to in the follow-up so I hastily signed up for the job. Allow me to update you on what's going on.

So far, I'm 90% complete in implementing this new "node select menu". I have to pester JonBob to add a new hook for my current implementation that will allow the user to select a vocabulary, but I don't think it's a big deal. Right now the vocabulary nam is hard coded.

Here's my design decision for now and what I've implemented. Hopefully, I'll have a patch by tomorrow. I agree with you that I am aiming for a feature that would allow many-to-many relationships but that wasn't something I would have been able to code in a couple of days and I need a solution by Friday. So I decided to do the most obvious and easy portion of the full feature: one-to-many relationship. Not much but I think sightly more flexible than the current select/drop down field.

Here's how it works so far:

1. The user creates a term to hold the nodes to be used as options.
2. The user adds as many nodes term to be used as select options.
3. The user selects the vocabulary word that contains the terms that this new content type would display. This vocabulary holds all the terms that flexinode can use as values, much like image.module and forum.module
3. When the user clicks on "Add Node Select", a drop down many, much like select menu appears as an option.
4. The user then selects which term in which the nodes used for options reside.
5. Now, when the user clicks to create a new flexinode type, an options is displayed, once again, much like a select menu.
6. When the user views the content of the new flexinode, the node selected as an option is display, linked and ready to be clicked and viewed.

This allows the user to create different terms holding various different nodes. The nodes are then available as options when creating a new flexinode content type. It only cares about nid and title of the node so it doesn't matter what node type you use.

This should probably be considered a hack rather than a sound long range implementation. For now this is what I've done and it should be enough for most problems...

robertDouglass, this solution hides the link, but it now requires an extra click to go to the publisher's link. But if you're using weblink.module, then you can manage those links to the publisher within a taxonomy term and also treat them as first class citizens. I hope this is good enough.

1) When defining a flexinode, the user can decide to which types of nodes the flexinode can make relations, and what kind of relations they are (1:n, n:m).

I agree with you that I'd like to have N:M relationship in the end. But that would require alot more code and definately, it would require a separate table to maintain the relationships. I don't have the time at the moment to write all the code taxonomy.module already does. But taxonomy.module is perfect if where only trying to implement 1:N. This means that you get a list of nodes to choose from when creating a new flexinode with a link to the selected node.

2) Given an instance of a node which can have relations, it should be possible to either choose a related node from the list of existing nodes or create a related new node, whereupon the relation is formed automatically. For example, given a Person node which can have addresses, there should be a button for 'new address' as well as 'link to address'. It would be rather cumbersome to always have to create the address on a different page, go back to the person and then establish the link.

This assume that N:M relation. Let me assure you that I'm hoping to do that soon after I get what I'm current implmenting. For now it's going to have to be clumbersome and force the user to 1) create the necessary address nodes, 2) add them to a term, 3) the link them to the Person node as they create a new person or modify an existing one. We could make it easier by providing a user-friendly GUI but that's another issue.

3) The relations should have names. This will allow us to make queries later, like 'give me all people who are linked to this address'.

Once 1:1 relations are implmented with taxonomy.module, each term would be the name of the relation.

4) Some relations are exclusive. An PhotoID which is linked to a User doesn't show up on the list of available nodes for other Users.

This is for another version. For now, a node can be selected as an option as many time as they want. I think this would be good feature for future versions.

5) User permissions must apply. User who instantiates a flexinode can only link to flexinodes for which he/she has permissions.

This one is a biggy... I didn't think about this one and I'm not sure how this would work but I believe if node_load() uses node_access() I think this should automatically happen. I haven't done any testing and I'll need to ask JonBob or some other person who more knowledgable. I think this should be implmented ASAP though.

6) Default rendering of a relation is a hyperlink to the related node with the text from a standard field (title).

Done.

7) It is possible to define an alternative to the default in 4. Perhaps specify a template which renders the related node and merges the output to the main node, like an include. For example, a Person node can be related to several company nodes. The company node template ouputs the company name, company phone number, but skips the company address. Name and phone number from all linked companies are outputted to the person page and there is no hyperlink to the related nodes.

Interesting idea. No idea how this would work. It would probably be implemented in _format() to determine the template... A more practical solution might be to see if that's something that should be handled by CSS. The linking is another issue I assume.

Last Note:
-I'm starting to think that a full-blown n:m relations between nodes is more on a module level. It's quite similar to taxonomy.module. It would allow hierarchy and relationships that are 2-ways.
-I also think that we could expand this current hack to allow the user have more flexibility in selecting which field to use as values and how they are displayed...

I'm not sure what to call this field type... I'm leaning towards "nodeselect"...

Any suggestions?

Well, here's the file I promised yesterday. A new flexinode field type call "nodeselect"

It allows the user to select a term(i.e. relation) within a vocabulary as options.

-Download the file and add it to the contrib directory below the flexinode.module directory

1. Create a vocabulary called "Node Select" (This is required for now)
2. Create a term
3. Add the nodes you wnat to use as values of your drop-down/select menu
4. Add a Node Select Menu to your flexinode
5. Create/Edit the flexinode and the nodes within the selected term will appear as options in your dropdown menu
6. The select value (node) appears as a link in the flexinode

Until JonBob gets around creating a hook to allow the user to select a vocabulary of their choice, "Node Select" is required.

Let me know what you think. It was a quick hack, so I'm sure there's alot of room for improvement.

The settings hook you requested is now available.

Jonbob can you please let me know if you can set up a new flexinode field type similar to this nodeselect one for pages.
That is I need a select field that allows you to choose from a drop down list an item of "page_type = flexinode_pagetype"

1. So lets say we have added a flexinode called textbooks and added 5 books of that type of flexinode page
2. Now we want to add another flexinode called courses.
3. In the courses flexinode you now want to add a new field (just like you would add a text line field or textarea field) but it will be a new field type (one you will have to write jonbob) called something like 'page type select'
4. Page Type Select : will allow you to list (dynamically when the form is shown and you hit the drop down list - or before) all of the page types (textbooks in this example) that you specify.
5. This will be similar, but not the same as, the categories check box that says what page types to apply the category to. I dont think you will be able to use the categories for this, as you want to be able to list the text books down the page, but I guess you may want to use categories as it may(or may not) simplify things.
6. When adding a new Course (2 above) page, you will have a choice of selecting one of the textbooks that get listed in the drop down select menu. This may also be a multi-select so that you could choose more than one textbook for a course.
7. If this could be done - brilliant. I cant seem to figure out how the flexinode fields work but if some one can point me in a good manual I will try do this myself

I am going to post this as a new thread which is here so please post to it

Any updates for this in Drupal 4.6? I've tried this upgrade and it doesn't work in 4.6 (errors).

Any updated on this? Flexinode, while it supposedly extends Story, doesn't pick up any taxonomy fields (at least it doesn't in mine - am I doing something wrong here?)

bump...

4.6 version please? If I understand correctly, this would allow picking a node from a select box, determined by a vocabulary selected. If so, great idea, and at least a simple form of relationship, where we have none now.

Any news about flexinode relations??
This will be very usefull!

http://drupal.org/node/28480 please have a look at this node/thread. I would really like the flexinode relation to use this approach.

I just tried to download the field_nodeselect.inc attachment that John Hwang added on August 12, 2004, but I got an error message that says, "You don't have permission to access /files/issues/field_nodeselect.inc on this server."

I believe there are existing modules which perform node-to-node relations. These function for all node types, not just flexinodes.

Clipper (versions 4.5, 4.7)
Relativity
Tagnode (4.6)

as another commenter said, there is another module that does what relativity does...