jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Nuescheler" <david.nuesche...@gmail.com>
Subject DM Rule #6: Files are Files are Files.
Date Sat, 07 Jul 2007 11:30:01 GMT
Explanation:
---

If a content model exposes something that even remotely "smells" like
a file or a folder I try to use (or extend from) nt:file, nt:folder
and nt:resource.

In my experience a lot of generic applications allow interaction with
nt:folder and nt:files implicitly and know how to handle and display
those event if they are enriched with additional meta-information. For
example a direct interaction with file server implementations like
CIFS or Webdav sitting on top of JCR become implicit.

I think as good rule of thumb one could use the following: If you need
to store the filename and the mime-type then nt:file/nt:resource is a
very good match. If you could have multiple "files" an nt:folder is a
good place to store them.

If you need to add meta information for your resource, let's say an
"author" or a "description" property, extend nt:resource not the
nt:file. I rarely extend nt:file and frequently extend nt:resource.

Example
---
Let's assume that someone would like to upload an image to a blog entry

/content/myblog/posts/iphone_shipping

maybe the initial gut reaction would be to add a binary property
containing the picture.

While there certainly are good usecases to use just a binary property
(let's say the name is irrelevant and the mime-type is implicit) in
this case I would recommend the following structure for my blog
example.

/content/myblog/posts/iphone_shipping/attachments [nt:folder]
/content/myblog/posts/iphone_shipping/attachments/front.jpg [nt:file]
/content/myblog/posts/iphone_shipping/attachments/front.jpg/jcr:content
[nt:resource]

Mime
View raw message