jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Miner <chris.mi...@luxoom.com>
Subject Re: Jackrabbit physical folder
Date Mon, 10 Jul 2006 15:18:40 GMT

Perhaps I don't understand your question, but isn't this how it already
works out of the box?  For example fire up the downloadable demo,
and edit the main page.  Add a "Samples: Text and image paragraph".
Choose an image off the file system.  It is uploaded and resides in the 
repository.  Preview the page, and the image is delivered.  The  publish the 
page and again everything is there.  Is this not what you are wanting?

On Monday, 10. July 2006 15:33, Ramachandra Sankuratri wrote:
> My UseCase is as follows.
> Say a HTML file is stored in the Jack Rabbit Repository. It has to refer
> to a .jpg file that is also stored in the Repository. How is this
> reference done so that it is valid both at the time of design (content
> editing) and after publishing.
> Thanks
> Chandu
> -----Original Message-----
> From: Jukka Zitting [mailto:jukka.zitting@gmail.com]
> Sent: Wednesday, June 21, 2006 2:50 AM
> To: users@jackrabbit.apache.org
> Subject: Re: Jackrabbit physical folder
> Hi,
> On 6/21/06, Ramachandra Sankuratri <ramachandra.sankuratri@plateau.com>
> wrote:
> > Please refer to JSR170-1.0.pdf(spec) - "5.1 A File System-backed
> Content
> > Repository"(page41).
> >
> > Does it mean that the layout specified in this example cannot be
> > retained in the file system-backed content repository?
> The examples in the specification illustrate potential ways of
> implementing the standard. Jackrabbit chooses a different approach of
> using "item states" instead of files and folders as the principal
> storage mechanism.
> The item states are persisted through a persistence manager component
> (of which we have a few) that decides the physical layout of the data.
> However, the item state design doesn't really map well to a
> traditional file system structure, it uses an id-to-content mapping
> instead of path-to-content, so it would be quite difficult to achieve
> the proposed storage layout.
> Even more, Jackrabbit is designed to be completely in control of any
> changes to the underlying storage, so even if we supported a
> "traditional" file system storage, you wouldn't be able to modify the
> contents of the files directly without major customization of
> Jackrabbit.
> What is your use case for wanting that kind of a storage model?
> BR,
> Jukka Zitting

View raw message