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 22:40:23 GMT
Upon re-reading the infamous Content Modeling threads, I have decided
to follow the prinicple of not using the REFERENCES unless necessary.
My application level name, which are the node names, will work just
fine as pointers.  In fact, that's what I had originally done.  I was
going to use references because I anticipated that it would make some
of my other work easier, the methods that allow you to get all
referencing nodes, for instance, would be very convenient.   But I
guess I'll do that work by hand.

On Tue, Aug 10, 2010 at 3:01 PM, ChadDavis <chadmichaeldavis@gmail.com> wrote:
> 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