Reports may have many forms. In this short tip we'll focus on the Display Table Macro. It allows to list a number of projectdoc documents (aka Confluence pages with our Document Properties Marker Macro) that match the given query constraint. The list of results is rendered in form of a table: each document of the result is rendered in a table row, each property of the document, in a table column. | Name | Property 1 | Property 2 |
|---|
| Document 1 |
|
| | Document 2 |
|
| | Document 3 |
|
|
In the above table the empty cells will be filled with the "Property 1" / "Property 2" of the documents named "Document 1" to "Document 3". | Note Box |
|---|
The rendering may also be in other formats, but we'll keep it simple here. It is recommended to use this macro for tables and the Display List Macro or its cousin Display List Template Macro for lists. These macros may render trees of results, while the Display Table Macro renders the result list always flat. |
The Display Table Macro has a couple of parameters, but for this short example we focus on two of them: Select: Enumerate the properties you actually want to render in the columns – if not specified the Name and Short Description is rendered per defaultWhere: Specify the query constraint
Note that the name of a property you use as constraint must not contain spaces! Hence we type "LevelofExperience", which is not easy to read. We therefore recommend to use property name delimiters ($<Property Name>) so that projectdoc will do the translation for you. The following screenshot shows the altered Where parameter. 
One could argue that this is not really easier to read: | Code Block |
|---|
| $<Type>=[Tip] AND $<Level of Experience>=[Novice] |
But it comes with an additional feature! By using the square brackets on the side of the expected value you can make an exact match. While in the before mentioned query you may also find document with types having the string "Tip" in it (like "Favorite Tip" or "My Tip of the Month"), the second version only allows types that match this three letter word (> T i p <) and nothing else. | Tip Box |
|---|
And to put more sugar on the ugly special syntax: you can use the property value of your current document in your queries as in | Code Block |
|---|
| $<Type>=[${Type}] AND $<Level of Experience>=[Novice] |
Note that we match type with an exact match to the same type our document is type of. One important caveat: In case your document may have multiple values for a property (for instance for Tags), you would need to use the list constraint like this: | Code Block |
|---|
| $<Tags>~(${Tags}) |
And just in case you are wondering: The left and right property need not to be the same. They are often, but not always as the following examples shows: | Code Block |
|---|
| $<Authors>=[${Name}] |
The example shows a Resource document that lists its authors. A document on a person may want to list all known resources. Note that we do not need to use the list operator here, since the document has only one name (splitting the list of authors and matching the values individually is done automatically for you by the projectdoc Toolbox). For more information on constructing constraints, please refer to Search Tips! |
| 
