Hi Jukka, the reason for this requirement is that every sub-area potentially could add some information to the "common" nodetype definition. Another requirement is that this customization of the nodetype must be possible from a web interface.
If I have correctly understood your proposal, If I add child nodes specific for a sub-area I have to verify every time I access (or create) a node of that type if there are sub-nodes containing the specific information and then treat this information as I need. I think that adding mixin property for each customer (or, better, each sub-area) it's similar to this. I'm now thinking of using a default workspace, used only by the "admin" user which serves only for creating other workspace (one for each customer). Each time I create a new workspace, I then define the "common" nodetypes with namespace suited to the workspace name (for example). Then, I can model the different sub-area with folders under the workspace. Every time I define a sub-area, if the user in that sub-area wants to add some information to the "common" nodetype definition, where can I store this information? Probably I can create a child nodetype containing the properties added, and modify the "common" nodetype definition of that workspace. Do you think there's a different approach I can use? BR, Luca Jukka Zitting wrote: > > Hi, > > On 5/31/07, Luca Tagliani <[EMAIL PROTECTED]> wrote: >> - each customer is divided into sub-area; each sub-area can have >> different >> definition of the same nodetype > > What's the rationale for this requirement? Could you solve it by > making your node types more unstructured, or by allowing > customer-specific extensions with mixin types or child nodes? > > BR, > > Jukka Zitting > > -- View this message in context: http://www.nabble.com/Architectural-question-%28CM-application%29-tf3845514.html#a10891370 Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
