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).
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?
