Short introduction on using data tables or using views on data.
Handling these Requirements
So what are the options to handle these requirements with the tabular approach and what is an alternative?
The alternative is single sourcing: Instead of adding lines to a table we see each line as an entity for which we create a new page. Information form these pages, single sources of truth for a particular information like the connection information for a particular team member, can be accessed and compiled in different contexts. Each representation for such a context we call view. So in different contexts you may have different views on the same information.
| Name | Christina Meyer |
|---|---|
| christina@example.com | |
| Phone | 098 321-123 |
| Mobile | +01 123 23451 |
| skype | tina.m |
| Name | Michael Suba |
|---|---|
| michael@example.com | |
| Phone | 098 321-204 |
| Mobile | +01 123 23671 |
| skype | super.mickey |
| Name | John Doely |
|---|---|
| john@example.com | |
| Phone | 098 321-451 |
| Mobile | +01 123 24656 |
| skype | mycorporationme |
Let's have a look at how we can engage the additional requirements we have listed above!
Selecting on Information
Selecting on information on a table can be done by filtering. Filters may reduce the amount of columns and the amount of lines. You can have controls where you type and automatically prune the table.
How can we approach this requirement using single sourcing?
The page holding the contact information for a person can be based on a blueprint to make it easier to add new members and provide the information that is most relevant to the team. A blueprint is therefore a tool to support authors to compile similar information in a similar way and it shows the author which information is typically expected on such a page. This guidance is implicit with the table approach. The format and layout is defined by the order and number of columns of the table.
There is a doctype for Person that provides a blueprint with common information one expects to find in an address book.
This doctype is part of the Core Doctypes, a free doctype add-on for the projectdoc Toolbox.
Information that should only be visible to team members having certain roles could be added on separate pages. The access to these pages is restricted by the wikis access control and are transcluded on the public page. Therefore the transclusion will only happen if the user has sufficient access to the restricted information. This feature is difficult to master with a table approach. You would need to have a tool that allows to grab information from an alternative location and render it into the page at request time. This is what transclusion does with Confluence tools.
You can add information in different formats. For instance the telephone number in form of its extension and in full format. You may also define different type of team members where different types of information is relevant.
Not shown here, but you can use the Display Document Property Ref Macro to render a property value and append or prepend additional information. This way you could have a property Phone Extension and a property Phone Number where the Phone number reuses the extension information. If the extension for a team member changes, the update is only needed in one place.
To automatically render the information of all team members in tabular form, use the Display Table Macro. This macro allows you to query for team members with certain properties and select to show only the personal information that is relevant to your use case. That is you have the information of team members in one place and then have multiple views on this information by using the Display Table Macro.
With the table approach this table is automatically provided. But since it is hard wired, there is only one view on that table (with some considerable variations if you add code for filtering and sorting to that table).
