You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 14
Next »
Property values should only change when a document is saved. They should not be dependent on request-time. If they are, then they are called 'dynamic'.
The concept of dynamic property values should be mastered by users right from the start.
Using dynamic property values with the projectdoc Toolbox seems quite natural. Especially novice users may not be aware of the issues that come with them.
This short article explains the problem with dynamic property values and shows use cases to handle them.
The information is based on the projectdoc Toolbox version 5.2.
Problem Description
When a user edits a document, only one document at a time is changed. Multiple users my edit multiple documents at the same time, but for the system most of the documents stay the same, only a number of them is altered.
A document may use values from other documents. This is the case if for example the Tags Property is referencing tags. It uses the name of the tag documents to render as values for the Tags Property. When a service document lists the systems it requires, then the service document uses the names and maybe further properties of the system documents, to render the values of its properties.
When only one document is changed, the property values of all other documents are calculated and readily available.
When all projectdoc documents are erased, they can be rebuilt from scratch, since all information is actually derived from Confluence pages. Some information architectures that seemed sound when used in the one-document-at-a-time context will now show if they can cope with the from-scratch context.
One issue may be with circular references as property values. References should be pointing in one direction. The projectdoc Toolbox will report circular references accordingly. Sometimes those circular reference first show up in the from-scratch scenario. That is because a value may be available from a existing document, but not if the document needs to be calculated.
Property Value versus Document Body
The document body is the part of a Confluence page that contains all the sections.
References in the body of a document are no problem. This is because they are always rendered at request-time, never stored in Lucene or in a cache.
Therefore the rendered text in bodies of those documents cannot be found in searches.
Another issue are dynamic properties. This may be more dramatic than circular references. Users may experience dynamic property issues even in the one-document-at-a-time context. The property values of such documents may often be considered as as not up-to-date.
Definition
The value of a dynamic property is dependent on the request-time.
Typically property values must be rendered at the time a page is stored and must not change due to external events. A property may reference another property. If a referenced property changes, the document with the reference is informed and the property value is updated accordingly. Changes only happen when a document is stored. A dynamic value does not reference another property value, but builds result sets at request-time based on queries or fetches information from other resources then projectdoc documents. The update mechanism is not applied to dynamic values, therefore dynamic values represent the value at the time they where stored. This is most likely an out-of-date value.
However there are use cases, where dynamic property values can be a valid solution. But special considerations need to be made: the property should probably not be indexed (noindex) and always be rendered at request-time (in other words: not be cached, no-render-cache). Or it may not even be considered to be a property at all (no-property, available since version 5.2).
Modes
The mode to handle dynamic properties is defined by the administrator via the configuration screen Dynamic Property Value Handling.
The following modes are available with the projectdoc Toolbox with version 5.2.
| Mode | Description |
|---|
allow | No restriction. Dynamic values are allowed. Users are responsible to use them correctly. This mode is used for backward compatibility. |
lenient | Dynamic values are allowed, and if proper control are not set, then no-property is assumed. The following controls are considered proper: Health checks will signal the use of deprecated features of macros considered to be dynamic. This mode may be selected to allow users to use dynamic values. |
strict | Dynamic values are allowed, and if proper control are not set, then no-property is assumed. The following controls are considered proper: This mode will be the default mode for the next major version of the projectdoc Toolbox. It is the recommended mode for new users. |
explicit | Dynamic values are allowed, if proper controls are set: The implicit flagging of no-property when a dynamic property is encountered, is not allowed. This mode should only be used for testing the health of documents, not as a runtime mode. |
block | No dynamic value is allowed. This mode may be helpful to find all locations of dynamic values with a health check. Not recommended as a runtime mode. |
Health Service
Administrators may check the current status of the projectdoc documents by the use of the REST service projectdoc-internal/1/health/find-dynamic-values.
The service allows to check spaces with different modes.
For version 5.2 of the projectdoc Toolbox the default mode is allow for compatibility reasons. For new users a value of strict or lenient is recommended.
Health Logger
Administrators may use the health logger de.smartics.projectdoc.healthCheck.dynamicValues for more logging output.
See Logging for more information on loggers.
Resources
More information on this topic is available by the following resources.
