Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (herse.apache.org: domain of quintesse@gmail.com designates
 66.249.92.175 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=VE7EgqBDEmKS6jIkb3zTgC7dWM6wy5EjJbLrPFwiCYpiBD9KwF9TLALmpXcfAj3oz8tTv2T65whF6msPVb5lOM6gJEctGUkx6rwluygM6CKl15VoU42pmi4vGl6bONATm5DT4+uR8l2z3CgpjvGYEUev9qg5Zp+QF0pAPz+hG6c=
Message-ID: <8641fd7c0707100438r180e070m2819019cc3de48a5@mail.gmail.com>
Date: Tue, 10 Jul 2007 13:38:22 +0200
From: "Tako Schotanus" <quintesse@gmail.com>
To: users@jackrabbit.apache.org
Subject: Re: DM Rule #6: Files are Files are Files.
In-Reply-To: <eb7e2190707070430h3cb49fc2sf55f38a0a79c0f10@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <eb7e2190707070430h3cb49fc2sf55f38a0a79c0f10@mail.gmail.com>

Agreed on the nt:file/nt:resource bit. I'm not sure what your reasons
are to add extra properties to the resource instead of the file
though. Care to elaborate a bit more? :-)

On 7/7/07, David Nuescheler <david.nuescheler@gmail.com> wrote:
> 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]
>