jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tako Schotanus" <quinte...@gmail.com>
Subject Re: Questions regarding nt:file and nt:folders
Date Tue, 07 Aug 2007 22:42:24 GMT
On 8/7/07, qcfireball <qcfireball@yahoo.com> wrote:
> 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.

Unless of course you want to keep track of folder and file renames.

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?

I imagine the reason is "content re-use", an nt:resource is an anonymous
item that could possibly belong to an nt:file and several nt:linkedFile

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?

I think it's nothing more than registering a new node type, like this for

[foo:i8nResource] > nt:resource
- jcr:language     (STRING)

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.

I have no idea, sorry.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message