| 1 |
attached_node.module
|
| 2 |
|
| 3 |
Written by Mark Howell 2004
|
| 4 |
|
| 5 |
Some of this code was lifted from other modules, including image.module.
|
| 6 |
Update Aug 18, 04: I'm trying to keep up with changes in CVS as preparations
|
| 7 |
for drupal 4.5 are made. This code isn't as frozen as I thought it was,
|
| 8 |
so I apologize if the docs are out of date or the code doesn't work. -MH
|
| 9 |
|
| 10 |
Purpose of this module:
|
| 11 |
|
| 12 |
Allow users to refer to other nodes from within the body or teaser of a node.
|
| 13 |
Provide a somewhat standard means of formatting the link to such nodes.
|
| 14 |
Allow user to customize position and attributes of this link/reference.
|
| 15 |
|
| 16 |
This is implemented for the most part as an output filter.
|
| 17 |
|
| 18 |
Installation:
|
| 19 |
To setup this module, just place attached_node.module in your modules directory,
|
| 20 |
then go to administr->input formats and click "configure" to configure whatever
|
| 21 |
input format you want to use this feature.
|
| 22 |
|
| 23 |
Enable "Attached Node Filter" and save your configuration.
|
| 24 |
|
| 25 |
Click the "configure filters" tab to configure all filters for this input format.
|
| 26 |
|
| 27 |
There will be a section for "Attached Node codes". Click the
|
| 28 |
"Enable Attached Node codes" checkbox to turn this filter on.
|
| 29 |
|
| 30 |
Additionally, if you want your users to be able to specify parameters for
|
| 31 |
displaying each node, put them here for each node type.
|
| 32 |
|
| 33 |
Common parameters include "title" for most node types and "res" for image
|
| 34 |
nodes. "res" can be set to any of the resolutions you configured with the
|
| 35 |
image module. A value of "original" will display the original resolution.
|
| 36 |
Parameters to avoid include nid, uid, teaser and body.
|
| 37 |
|
| 38 |
That's it. It's ready to use. Test it out by creating a node (say it's
|
| 39 |
nid is 123, for example). Then create another node and attach the previously
|
| 40 |
created node to it using the following syntax:
|
| 41 |
|
| 42 |
[node:123]
|
| 43 |
|
| 44 |
You can place this tag anywhere in the body and it will get translated on the
|
| 45 |
fly.
|
| 46 |
|
| 47 |
|
| 48 |
The most popular use case for document management in this crowd seems to be
|
| 49 |
attaching images to stories and blog entries. Arguments have gone round and
|
| 50 |
round about what is the best way to do this, and in the process of trying to
|
| 51 |
figure out what will make the most people happy, I have come to a compromise.
|
| 52 |
|
| 53 |
I originally designed a relational database model for managing attached nodes
|
| 54 |
and all of the maintenance code that goes with it. After much thought, and
|
| 55 |
coming across the filter that the image module uses, it occurred to me that
|
| 56 |
perhapse the best solution was the simplest one: use meta tags.
|
| 57 |
|
| 58 |
I took the concept that the image module used for tag format and made it a bit
|
| 59 |
more generalized. The format currently is of the form:
|
| 60 |
|
| 61 |
[node:NID, align="center", height="50", title="look at this stupid article"]
|
| 62 |
|
| 63 |
..where NID is the node id of the node being linked to, and all of the optional
|
| 64 |
parameters are specific to whatever type of node is being linked to.
|
| 65 |
|
| 66 |
Image nodes, for instance, would display a thumbnail in this tag's place (similar
|
| 67 |
to how the [image:NID..] tag works with the image.module. Each node's allowed
|
| 68 |
parameters are specified on the filter admin page. You can allow your users to
|
| 69 |
override whatever node properties you would like. Some don't make sense (like nid)
|
| 70 |
so caveat emptor, but nothing gets overwritten unless you explicitly set up
|
| 71 |
permissions to do so. Additionally, these properties are only overwritten for
|
| 72 |
the purposes of displaying the node. Nothing is saved to the database.
|
| 73 |
|
| 74 |
Security is adhered to by checking <code>node_access("view", $node)</code> for
|
| 75 |
every node that gets translated.
|
| 76 |
|
| 77 |
The tricky part doesn't exist yet. On each form edit page, there should be a
|
| 78 |
link to "attach node". This should pop up the "Create Content" (node/add) page.
|
| 79 |
Along with this page will be the understanding that whatever node gets created
|
| 80 |
will eventually be referenced from the original node. This can be done several
|
| 81 |
ways and I have not decided yet how exactly this will be done.
|
| 82 |
|
| 83 |
1. Form Keys:
|
| 84 |
The original node (parent) will have a form key generated. Children nodes
|
| 85 |
will need to maintain this key until they are saved. The form key gets placed
|
| 86 |
in a table awaiting the parent to be saved. When the parent is saved, meta
|
| 87 |
tags from all children are appended. This could be done at the preview phase
|
| 88 |
as well.
|
| 89 |
|
| 90 |
2. Javascript:
|
| 91 |
Upon saving a child node, the node body form element of the parent will have
|
| 92 |
a meta tag referring to the child appended to it. This will allow the user
|
| 93 |
to immediately customize the position and attributes of the attachment.
|
| 94 |
|
| 95 |
|
| 96 |
There are other techniques, but these are the two that I'm most considering.
|
| 97 |
|
| 98 |
-Mark Howell
|
Parent Directory
| 
Revision Log
| 
Revision Graph