keizo/weblog

I’ve been researching this for a while. Images and files as nodes don’t feel right to me. In Drupal I have come to think of a node as any page that has the intention of being displayed. A typical node has some text content, often with other embedded content like images or videos. A node is the destination. Images are things that belong embedded in a node and are not the destination itself.

Typically in the computer science realm a node is a data abstraction that hold any type or object. Some argue that therefore an image or file should be their own node. However, images and files are typically not the destination — they are merely parts that belong in a node. Compare that to a C++ node used in a linked list. A C++ node might contain a class. This class would contain some variables. The variables in that class are equivalent to images and files. The variables are not a node in that list.

I think files should be implemented similar to the method that comments are implemented in Drupal.

The following are notes that I’ve gathered supporting this.

### Dries summer of code proposal

>Improved file handling. Make it possible to mix database and file system storage on a per post basis, further abstract the storage model so we can support distributed storage solutions (like Amazon S3), apply node-level permissions to a node’s files through a light-weight file.php layer. **Do not implement files as nodes.**

### from Mar 2006, Dev list

*Drupalista*
>Why don´t you get together and **produce ONE killer-img-module**? Why are
there 10 different modules for image uploading and handling?

>Make ONE. Only ONE that works, please.

*Stefan Nagtegaai*
>There are so much image related modules in contrib, which are mostly redundant in (a great part of) their functionality.. So I think [Drupalista] is right..

### from Dec 2005, Dev list

*Earl Miles*
>For people who write articles on my site, **I find simplicity to be the absolutely most important issue**. They **want to be able to attach an image to a node and be done with it**. If they have to set up an image node and then figure out how to link that image node to their article, they’re going to have a lot fewer articles with images.

*James Walker*
>well “set up an image node” doesn’t / shouldn’t need to involve going to node/add/image and creating the image then going back to node/add/story, etc.

>I.e. img assist (and htmlarea) both allow you to create image nodes when you attach. I’ve heard both that **img_assist** is sliced bread and that **it’s still too confusing**, not right, something…

*Rowan Kerr*
>You could keep “nodes” and “files” separate…

>Where nodes are any kind of actual content that is typed into the site
>And files are anything that is uploaded by the user

>Then you’d have node types and file types.. that could decide just how to display different things.

>nodes would be stuff like: blog, page, article, book page, etc…
>files would be stuff like: document, image, spreadsheet, movie, audio…

>Because files that are uploaded, I would not really expect should be
given a normal title, body, published/unpublished, etc… that nodes
(actual _content_) would have. Really, node’s don’t have a filename,
file size, mime type, filesystem path, etc…

>Then you get into more of a document management system where
things are clearly defined instead of combining content and external
files under one container.

>I think this is the way to go, three base types: user, node, file

>*Tim Altman:* Don’t forget comments.

*Dries Buytaert*
>>1) All downloadable files should be nodes.

>**I disagree with this. If the sole purpose of the file is to be downloadable, there is no value in making it a node. It adds clutter and administration overhead.**

*Robert Douglass*
>Let’s say that the relationship is called “attached file”.
The next step is to be able to search through all existing nodes that can possibly fill the roll of “attached file” while creating a new node. A current limitation of our system is that I’d have to upload the same PDF 3 times if I want to have it appear on 3 different nodes. This, we can all recognize, is crap. I should be able to reuse the already uploaded PDF.
This raises two issues: a search interface for media assets is hard to build. Image assist is the best working example we have, and with all due respect to its greatness, it is still clunky (haven’t tried the newest version though).

### on the fence / for nodes

There was lots more than this, but I only copied these.

*Ber Kessels*
>This is a point of endless discussion in Drupal.

>In myworld a node is a “thing” where all sorts of data meet. The node
is nothing more then an entity to bind that data and make it a “thing”.

>Unfortunately, in Drupal nodes are only used for content. For posts, to
be more precisely. So over time drupaleers tend to think about a node as
a post. Rather then the much more powerfull abstract “thing”it actually
is.

>So, in this a file would be nothing more then a “thing” of type
“document”, “image” etc.

*Sebastian wrote:*
> Frankly I feel all images should be a node. Even if an image is included
in a content node just for spice or illustration, very likely these images could be thumbnails that link to a larger version. Same story if I include a true photo in a content node, it will most likely also be a thumbnail linking to the full image node.
So I see no reason to build two frameworks for handling images when one will do. Why the arbitrary separation? They should all be nodes, and if we need organizational separation of “photos-available-in-galleries” vs “spice-and-illustration-images”, that should be handled via taxonomy, and only the desired terms made available in menus/galleries.

This entry was posted on Saturday, March 17th, 2007 at 7:04 pm and is filed under , . You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.