jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ChadDavis <chadmichaelda...@gmail.com>
Subject Re: reference properties across workspaces
Date Tue, 10 Aug 2010 21:01:27 GMT
On Mon, Aug 9, 2010 at 5:58 PM, Justin Edelson <justinedelson@gmail.com> wrote:
> 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).

The references I'm talking about are pointers to some "content type"
nodes, which define the various types of content that can be in the
system.  The references on a given folder point to the content types
that can be created in that folder.  This seems to match the use case
you cite.

However, the notion of having a separate tree for configuration, which
reproduced all of the namespace of the folders themselves seems a bit
counter intuitive.  Could be that I'm just not used to the
hierarchical thing.  At the same time, the reference seems perfectly
made for my task.  It is, afterall, referential integrity that I'm
trying to maintain.  And using a reference buys me the referential
integrity support.

I'd appreciate any further comments . . . .

> Justin
> 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