CMS Functionality In An nt:resource ?

[woolly <p....@lbs-ltd.com>]

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.

Re: CMS Functionality In An nt:resource ?

[David Nuescheler <da...@day.com>]

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....@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....@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.
>
>

Re: CMS Functionality In An nt:resource ?

[woolly <p....@lbs-ltd.com>]

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....@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.

Re: CMS Functionality In An nt:resource ?

[David Nuescheler <da...@day.com>]

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....@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.
>
>