4 messages in org.apache.jackrabbit.usersRe: CMS Functionality In An nt:resour...
FromSent OnAttachments
woollyOct 2, 2007 3:44 am 
David NueschelerOct 2, 2007 3:49 am 
woollyOct 2, 2007 4:05 am 
David NueschelerOct 5, 2007 3:27 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: CMS Functionality In An nt:resource ?Actions...
From:David Nuescheler (dav@day.com)
Date:Oct 5, 2007 3:27:02 am
List:org.apache.jackrabbit.users

hi phil,

i am sorry for not reading you initial post carefully enough. i think splitting the large xml file into various nt:resources may be a good solution, another way would be to introduce something like an xml-fragement node that just hosts an xml fragment in a single string or binary property and could be placed into any "standard" xml structure at the point where the desired granularity is reached.

i would assume that since your application probably wants to define how the xml is broken into pieces it may still require you to make those decisions in the application anyway.

does that make sense?

regards, david

On 10/2/07, woolly <p.b@lbs-ltd.com> wrote:

Thanks for your reply,

If I use a document view import (via session.importXML()) then the document is exploded underneath the node to which I import and the size of the repository increases enormously (an 8Mb file takes up 120Mb on disk or something silly!) That's why I've had to store some parts of the document as nt:resource so that I can get my full document in. Unfortunately, though, I still need CMS style functionality on some bits of the xml in the nt:resource. I was just wondering if there's a "standard" way of doing this, or if anyone had any good ideas...?

David Nuescheler-3 wrote:

Hi Phil,

I think you may be looking for what's called an XML DocumentView import.

This allows you to deal with your XML document on an XML-element/attribute level, when it comes to content repository features such as versioning, locking or query.

regards, david

On 10/2/07, woolly <p.b@lbs-ltd.com> wrote:

Hi all,

I have recently had a problem where I was trying to import a large xml document into the jackrabbit repository. The repository expanded hugely during import. I solved this problem by having some elements of the xml stored as an nt:resource node (as jcr:data with an xml mimetype).

Now I've got the problem that I want repository features such as versioning and referencing to apply to some parts of the xml that is stored in the nt:resource. Does anyone have any ideas on the best way to implement this? I'm thinking about taking the xml chunk I want to version out of the nt:resource and then storing it somewhere else. But then, what's the best way of making the link between the nt:resource xml and the new "exploded" xml?

Is there a better way to allow repository features to apply to parts of xml stored in an nt:resource?

Thanks for any help,

Phil.

-- View this message in context:
http://www.nabble.com/CMS-Functionality-In-An-nt%3Aresource---tf4554191.html#a12996511 Sent from the Jackrabbit - Users mailing list archive at Nabble.com.

-- View this message in context:
http://www.nabble.com/CMS-Functionality-In-An-nt%3Aresource---tf4554191.html#a12996738 Sent from the Jackrabbit - Users mailing list archive at Nabble.com.