Jump to:
| Project: | Outline |
| Version: | 5.x-1.0 |
| Component: | Code |
| Category: | task |
| Priority: | normal |
| Assigned: | beginner |
| Status: | closed (fixed) |
Issue Summary
Drupal's development tendency is to make everything more abstract and general instead of specific. The goal is to bring CCK into core. story.module and page.module have gone, because they were simple node types that can now be handled by node.module.
blog.module, forum.module, and book.module all remain, because they define more than a node type: they define a relationship between nodes. This is particularly true for book.module which defined an outline based on a top-level/parent/child relationship.
The parent/child relationship is injected in the node_add form from the URL like: http://drupal.org/node/add/book/parent/10257 with /parent/10257 appended to /node/add/book and the parent's nid (10257) is injected into the form:
<?php
$form['parent'] = array('#type' => 'select',
'#title' => t('Parent'),
'#default_value' => ($node->parent ? $node->parent : arg(4)),
'#options' => book_toc($node->nid),
?>pwolanin's latest patch is following a slightly different strategy within outline_form_alter():
<?php
// looking for url like node/add/book-page?book=$book_id/$parent
if (arg(1) == 'add') {
if (isset($_GET['book'])) {
$book = explode('/', $_GET['book']);
if (is_numeric($book[0]) && is_numeric($book[1])){
$book_id = $book[0]; //needs to be validated below
$parent = $book[1];
?>What I am wondering is both how useful and how difficult it would be to generalize the process of defining the relationships between nodes. I am thinking about the possibility of creating a node relationships module that can be used with the battery of CCK module (and especially http://drupal.org/project/computed_field) so that webmasters can define the relationship between nodes and the nature of this relationship.
When adding a node, the URL would look this way:node/add/node_type/key1/value1/key2/value2.
The keys and values would be extracted by the node relationship module, and injected into the form via hook_form_alter(), whatever the type of the form element (text, option, value, etc.).
The outline.module could be made experimentally dependent on that new module in order to define the value for 'parent'.
Obviously, I brink this up because we need this for outline.module, and also for another project I may be working on soon.
What do you think?
Comments
#1
I haven't tried it yet, but it seems the 5.x version of CCK includes a field type named "Node Reference".
Partly I though the query string (a.k.a. the GET method) was better since it would respect path aliases like node/add/foo -> add/foo
Also, this post has an idea worth considering: http://drupal.org/node/106287
#2
The post "Get book to inherit parent taxonomy" can be considered, but it is a different issue. Maybe open a feature request for later.
I hadn't noticed the "Node Reference" module before. Thanks for pointing it out. It doesn't do what we need, though, or only part of it.
1) It doesn't pass the reference via the URI, through the GET method like in your patch.
2) It makes a pull down menu with a list of all the nodes of a certain node type. We want to limit this list not by node type, but by volume_id.
For my other project, the reference would be yet another thing.
What I describe above is a general way to match a key/value pair passed via the URI or via the GET method to a form item whatever the nature of the key/value pair and the type of the form.
I am ok with the GET method as you coded it. Maybe it is more flexible?
#3
Well. The module is working now, and I gave up using CCK, so I set this as fixed.
#4