jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Edelson <justinedel...@gmail.com>
Subject Re: reference properties across workspaces
Date Mon, 09 Aug 2010 23:58:27 GMT
Hard to judge without knowing more about what this configuration data is, but if it doesn't
semantically belong in the publish workspace (e.g. If it configured how a folder's contents
are edited), I would probably store it in a secondary hierarchy. For example, the configuration
data for /content/news could go in a node at /configuration/content/news. This could also
help with access control (maybe you want to restrict editing of these configuration properties
to a different group than normal properties of your folders).


On Aug 9, 2010, at 4:40 PM, ChadDavis <chadmichaeldavis@gmail.com> wrote:

> I'm facing a design choice that I don't feel very qualified to make.
> Perhaps it's not so important, but I don't want to overlook any easily
> avoided consequences.
> I'm building a simple content management system.  I have documents in
> folders, etc.  I'm using a second workspace for a "publish" workspace;
> when users want certain content to go live, they publish them.  They
> are then cloned to the publish workspace.  Folders are handled
> similarly.
> Until recently, I hadn't thought of moving any other data to the
> publish workspace, other than the documents that are published, and
> the folders that hold them.  However, my folders have REFERENCE typed
> properties that point to configuration type data.  I'm hesitant to
> move this data to the publish since it doesn't seem related to the
> publish use case.
> But if I have a reference property with a value, when I clone the
> folder the reference will be invalid.
> So . . . any suggestions?  Is it common to have to clone over the
> entire depenency of referenced nodes?

View raw message