On Mon, Aug 9, 2010 at 5:58 PM, Justin Edelson <[email protected]> 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 <[email protected]> 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? >
