jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From qcfireball <qcfireb...@yahoo.com>
Subject Re: Questions regarding nt:file and nt:folders
Date Tue, 07 Aug 2007 19:11:20 GMT

I hope this provides you some clarity.

In reply to Bob's question (his text omitted for brevity):
Here are 2 scenarios involving files.  One involves a single file, the other
an arbitrary number of files.  The format of the text is: 
node-type|node-name, with children underneath, indented:

nt:file|<arbitrary name>
   nt:resource|jcr:content
       (p) jcr:encoding=...
       (p) jcr:mimeType=...
       (p) jcr:data=0x...... (binary content)
       (p) jcr:lastModified=...

nt:folder|<arbitrary name>
   nt:file|<arbitrary name #1>
      nt:resource|jcr:content
          (p) jcr:encoding=...
          (p) jcr:mimeType=...
          (p) jcr:data=0x...... (binary content)
          (p) jcr:lastModified=...
   nt:file|<arbitrary name #2>
      nt:resource|jcr:content
          (p) jcr:encoding=...
          (p) jcr:mimeType=...
          (p) jcr:data=0x...... (binary content)
          (p) jcr:lastModified=...

It seems to me, what you want to version is the nt:resource, NOT the
nt:file.  I am not sure what function or responsibility the nt:file node
provides, but as you know, the actual content resides in the nt:resource. 
It seems reasonable that you would want to version the ACTUAL item that is
varying, not the node that contains it.  You have mentioned this in your
post.  Mentioned elsewhere, I cannot find it right now, David mentions that
in his own use of the JCR, he rarely (if ever) extends nt:file, but
regularly extends nt:resource.

I would be inclined to have an implicit trust in his statement on this. 
Maybe naive, maybe not.  So, it would seem that an extension of nt:resource
would be preferable.


I have a couple additional questions to this issue of files/folders.

1)  why the additional level of indirection with nt:file?   If this is
analogous to a filesystem, the file IS the file.  What is the benefit of
nt:file and nt:resource existing as separate entities?

2) What is involved in creating an extended nt:resource node type?  Is there
a document discussing how to do this?  Or would I be able to figure this out
by inspecting the source code?

3) Because I know I will be asked, if extending nt:resource is a frequent
occurence, why is there not a "stock" version that would allow some
additional capabilities, such as extra arbitrarily named/typed properties? 
In the new world of development where Enterprises want to use more "off the
shelf" software and less custom written software, why would this not be a
part of the spec?  Some folks, perhaps in our Enterprise, would view this as
a deficiency rather than a benefit, due to the possibility of breakage as
updates occur.

Thanks.

MJKelleher
Principal Software Developer
The Nielsen Company
-- 
View this message in context: http://www.nabble.com/Questions-regarding-nt%3Afile-and-nt%3Afolders-tf4231254.html#a12040465
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.


Mime
View raw message