You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 4
Next »
The projectdoc Toolbox supports use cases with a collection of spaces. Some of these spaces provide general information, some are specific for a product, a project or a team.
A basic concept of the projectdoc Toolbox is the organization of spaces based on document types. For a space there is one location where a specific document should be stored. For a collection there should also be only one location for a particular document.
This tip shows how you can accomplish this – or at least how to get very close to this.
Prerequisites
Readers should be familiar with the different kind of spaces: index, attachment, topic, and workspace. If you would like to read more information on these space types, please refer to the tip Using Spaces.
Readers should know what space properties are and how they are used. Please refer to Using Space Properties on how to employ space properties.
Single Space
Each space may be an island. A team needs a space to collaborate, a corporation needs a space to provide information about a service to their customers. In this use cases everything is self-contained. No references are made between spaces and no space requires labels defined in another space.
Hierarchy of Spaces
These single space use cases are typically not very common if the corporation allows to share configuration and information. Then: No space is an island!
The projectdoc Toolbox allows configuration on space level using space properties. A space property can be delegated to a delegate space. Multiple spaces may share the same delegate space. In fact the projectdoc Toolbox assumes such a default space to have the space key IDX. This is only a default. The delegate spaces for a particular space are defined by the space property delegate-space.
Sharing configuration is one aspect of a delegate space. The other aspect is the provision of homepages for doctypes. Index spaces define categorizing document types like tags, categories, subjects, and types. This information is often shared between spaces. Usually there are some generic types that are used in every space.
Since index spaces have typically sitewide access. For a public facing website this information is by default open to anonymous users. You may restrict the access to particular pages, but the users with least privileges have access to the homepage and therefore to the configuration of this space.
Therefore the information architect may decide to store information with higher access levels in separated spaces. These spaces are called attachment spaces since they are attached to another space. In most cases this central space is an index space.
To attach a space to an index space, the space key is listed by the delegate-space property.
Sitewide Spaces
Examples for attachment spaces are address books, glossaries, and libraries. In case you have the use case to provide this information for all your spaces, your sidewide spaces will have a structure similar to the following:
- IDX - the sitewide index space
- ADDR - the sitewide address book
- GLOSS - the sitewide glossary
- LIB - the sitewise library
The configuration for the index space has these lines.
The search space will find documents in all spaces the current user has access to. The default space closure allows links from the index space point to pages in any spaces the current user has access to. The three attachment spaces need to be configured manually in the index space.
No matter on which page in a space of this configuration a user is on when creating a new document, the send-to-homepage function of the page blueprint wizard will find the correct location for this new document.
Specific Spaces
In case a team needs a couple of spaces to meet their collaboration needs, the basic structure of index space and attachment spaces is also a valid solution.
Instead of an index space with homespaces for various doctypes, a configuration space may be more handy.
