Page and Space blueprints are a great tool to structure information in Confluence. They support teams to create pages and spaces with focusing on the content, less on the structure, not on the layout. With this tool new pages and whole spaces can be created with wizards in very little time.
One great thing about blueprints is that they can be managed as add-ons. Teams can have their blueprints designed and maintained as versioned Maven projects. These add-ons can be easily shared by team working on different Confluence instances. Unfortunately creating new blueprints takes quiet some time. And the work is often not very rewarding since a little misspelling can require some minutes in getting it right. Error messages are not the API's strong suite.
After about two year of writing a number of blueprints for the projectdoc Toolbox, we finally came to the conclusion that we need to have some tool support to write blueprints. We want to come to the point where writing blueprints and create new add-ons with blueprint sets is no longer a great deal.
In the past we have come up with some simple observations that we like when using blueprints.
- Have sets of blueprints that work together, using existing blueprints
- Have at least one space that provides a basic structure for the domain of the blueprint set
- Create navigation by dynamic linking
- Provide a type blueprint for most of the blueprints
- Show pages of a given type
- Show child pages and a reference to the parent
- After the creation of a new space or new page, everything should be ready to work - no remove this, paste that
To create a blueprint you need to touch a number of files.
- There is the XML file containing the template,
- the Soy file to specify the wizard.
- probably a Java file to manipulate the blueprint context.
- Add localized resource files for one or more languages,
- create one or more index pages,
- and finally a number of edits to the
For projectdoc we also generate blueprints to create index pages (should you get lost of the doctypes homepage), special pages (such as - and currently the only one) content management homepage, which is a view for authors on the documents, and finally a blueprint that creates all pages of a space in an already existing page.
Since these are considered as basic support they are created automatically.
So the basic course of events is this:
If you start from new you probably would like to have some example files and your are probably not that fancy to specify a nice name and description. In this case use the following:
The project has configured quick reload.
Types of Pages
To make this simplification we define some constraints.
First, we think of pages as documents with properties (key-value pairs) and sections (a title with text, possibly nested). We call this a projectdoc document. With this in mind, we define a document type with a doctype descriptor (there is also a descriptor for spaces and one for the context of the add-on).
When we create new doctype add-ons there are typically three kind of documents:
- Documents that contain information of a given type (e.g. a doctype to document systems)
- Documents that categorize this type (e.g. system type documents)
- Documents that categorize this and other types (e.g. documents that specify phases in a lifecycle)
A System, a System Type, and a Type
With this a team may document a system (e.g. a JIRA instance), associate it with a system type (e.g. issue management system), and set a lifecycle phase (e.g. In-service). On the issue management page there will automatically be listed all issue management systems and on the In-service lifecycle page, all systems (and maybe other entities with a lifecycle) that are actually servicing will be shown. Only one document is added, but two indexing pages will automatically reference it.
We created a first beta version of the Doctypes Maven Plugin that should make it a lot easier to create these three kinds of pages.
We say 'should' since we just started the journey.
Everything starts with the archetype project. But you control the archtetype for doctype add-ons with the doctype:create goal which sets some defaults and makes creating new add-on projects quite easy.
To simplify this process of blueprint creation, we do specify one descriptor per document and space type (currently there can only be one space).
System, System Type, and Lifecycle Phase
Here is the example of a doctype (
it-system) with it own type category (
If you are looking for the declaration if the
it-system type, its here:
The type doctype provides a section to dynamically list all documents that are associated to this type.
it-system blueprint does not only provide the two properties explicitly stated. Since it derives from the standard template, all standard properties and sections are automatically generated.
Then generate all the blueprint related stuff (note there are XML schema files to support writing these). And startup Confluence with the Atlas SDK.
We started our internal beta (although the sources are already published on Bitbucket) to check how it is working. Needless to say that at this early stage it has some limitations:
- The syntax for defining sections is not final - property values (with alternate forms as seen above) and whole sections (without alternatives if you need to specify more than a placeholder) are specified in their storage format within an
- Only one space blueprint can be defined
- There are grammatical problems with the boiler plate texts (especially in German), so there is the need to run over the generated localization bundles
- No roundtrip: You should not need to edit the generated files (or if you do, should not use the descriptor again)
- Very simple wizards currently
- Currently the localized resources need to be written to the descriptor
- There is also a redundancy specifying the central base templates - but you won't see this until you need to create your own base template
We'll work to improve the tools to remove these limitations.
What is next?
As stated above the tools have some rough edges. So we need to run this internally first. If you are interested to use this tool, it is available at Bitbucket and available from our Nexus server.
Please check out the documentation for the Doctypes Maven Plugin to get everything set up. Do not hesitate to get in touch, if you have questions or are being interested in this topic!
Hopefully we can soon truthfully say: Creating Blueprints is fun!