projectdoc Toolbox

Doctypes and the Name List Macro allow to specify a range of valid tokens for a value. These values can be rendered by applying specific CSS styles.

Parent
Audience
Level of Experience
Expected Duration
30 min
Type

Speaking about metadata for projectdoc Documents we are often running into the requirement to define a range of values to select from. Furthermore we want to make these values visually appealing. The Status Macro provided by Confluence allows to render values with a great look, but fails to guide userson selecting proper values. It put the burden on authors to select the corresponding colour for a status value manually, making the uniform representation of these values cumbersome for the documentation gardener.

This tip introduces the Name List Macro and Tag List Macro of the projectdoc Toolbox and shows how to use doctypes and document instances to define a range of valid values for a document property.

Contents

Summary

This is what documentation architects need to do to provide a set of valid values for properties.

  1. Define the range of values and their representation styles
  2. Create one document for each value
  3. Add the Name List Macro (or one of its cousins) to the template

Define the Range of Values

Defining a value range is a one-time configuration effort usually designed and conducted by the documentation architect and/or the documentation gardener.

For this example we want to define this range of values:

ValueDescriptionOrderStyle
No team member is currently working on the task. Therefore it is currently open.00100background-color: red;
The team is working on this task.00200background-color: orange;
The team has finished the task.00300background-color: green;

Create Document Instances

For each value you need to create a document where you add the information or metadata for this value.

Select Doctype

First you choose the doctype. For status codes the use of the Tag doctype seems natural.

Create Parent Tag

To group all our status codes we define a parent tag document first.

You may add any information to this document, but its main purpose is to hold our three status tokens together.

Create Value Range

Add as child to the parent tag a new document for each value of your value range. All of these values are based on the Tag doctype.

Now we need to add some document properties to define the order of the values (Sort Key) and their visual representation (CSS Style Information).

Please make sure that the value for the CSS Style Information is indeed proper CSS (including the semicolon at the end!)

Note that the third column of the table contains document property controls where we add the hide control. This will signal the renderer that this line is of no interest to our readers and is therefore not visible in the view mode of the document.

Add one document for each value of your range as a child to the Status tag document.

This is the result:

Autolist tagged Documents

 

The doctype instances typically automatically list all documents with a given value using the Display Table Macro. This is very handy for a small amount of documents tagged with a given value (for larger sets of documents you may want to list them using different queries on dedicated pages).

Go the the Section with title Documents and change the Where parameter according to your selection requirements.

The example selects on the property name 'Status' (per default the doctype selects on the 'Tags' property).

$<Status> = [${Name}]

You'll find this name used in the following steps of this example.

For more information on how to specify search criteria, please refer to Search Tips!

Fixed, plain Values

 

If you do not need to add values dynamically as shown in this example, you can choose from a set of Selection Macros. An example for such a macro is the Iteration Macro with a predefined set of document iteration steps.

You cannot change the values of the macro. You cannot document your semantics of the values. It's take it or leave it.

Use the Value Range

Using the value range comprised

  1. the definition of a property using the value range by the template author (template) or author (document instance)
  2. the selection of an actual value by the page author

Define Range Property

To use the value range in your documents you typically ask the template author to define a blueprint and add the configuration to the template. In this example we will do this manually first. That is the a property is manually added to a document instance by the author.

Per Instance

For this example we assume that the author creates a Topic document.

Add a new property called 'Status' to the document by adding a line to the properties table (within the Document Properties Marker Macro). Use the Name List Macro as a value to the property.

Open the macro editor for the Name List Macro and set the following parameters:

ParameterValueExplanation
DoctypetagSelect on the Tag doctype. Please note that you specify the identifier of the doctype and therefore it is all lower-case.
PropertyStatusThis is not mandatory and only affects searching if specified via a blueprint.
Where$<Parent>=[Status]Select the valid values for this property. By defining an exact match we restrict the range to those values of doctype Tag whose parent document is the Status document we created in step one.

You may also limit the search for valid values on specific spaces. Please refer to Delegate Space for more information on how to use delegate spaces to define common information that applied to all delegating spaces.

Why not Tag List Macro?

 

Since we use the Tag doctype you may ask why we use the Name List Macro and not the Tag List Macro. The difference between the two is that the latter also includes the labels of a page as values. Since you want to control the range of valid values, the Name List Macro is a valid choice.

If you save the page, you'll see ... nothing!?!

That is because we just have defined a property and a valid range of values, but actually did not select one. Properties without a value are not shown by default (to not clutter the view with non-information).

The template author may select one as default, which would be 'Open' in this example or leave the selection completely to the author. See Select a Value for details.

Using a Blueprint

Specifying a property value for a class of documents is typically resolved by the creation of a blueprint.

In this case the template author adds the property with the configured Name List Macro to the table of properties using the Storage Format syntax.

Property Definition in XML
<tr>
  <th>Status</th>
  <td>
    <ac:structured-macro ac:name="projectdoc-name-list">
      <ac:parameter ac:name="doctype">tag</ac:parameter>
      <ac:parameter ac:name="property">Status</ac:parameter>
      <ac:parameter ac:name="where">$&lt;Parent&gt;=[Status]</ac:parameter>
      <ac:parameter ac:name="empty-as-none">false</ac:parameter>
    </ac:structured-macro>
 </td>
 <td> </td>
</tr>

I18N

 

For internationalization you probably want to replace the strings Status and Parent with a I18N key.

Select a Value

To select a value the author can check the valid set of values by deselecting the Empty Where Clause Handling.

Select one of the values and set it as the value to the Names parameter.

Save the macro and then save the page. The result is this:

Limitations

The Name List Macro has a number of limitations that we will address in future releases of the projectdoc Toolbox.

Clumsy Selection

The author needs to use a workaround employing the Empty Where Clause Handling parameter to get a list of valid values in the browser. She then needs to type (or copy-paste) the value.

PDAC-632 - Getting issue details... STATUS

Multiple Values allowed

 The Name List Macro also allows to specify multiple values.

While this is a valid use case on its own, it does not support the restrictive character of the use case we show here.

PDAC-630 - Getting issue details... STATUS

No Enforcement for Value Range

The Name List Macro currently does not force users to choose one of the values.

This is a valid use case to support authors to add values on the fly. It does not support the restrictive character of the use case we show here.

PDAC-631 - Getting issue details... STATUS