Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

The final part of this design guide concerns the actual modelling of a document using the Documents component. In this guide we will discuss best practices and considerations to create a readable and maintainable document. 

Note: this part does not focus on modelling a document using a Page. Some parts might be relevant though for both methods.

 

Panel
titleTable of contents
Table of Contents
maxLevel1

 

Getting started

A document model can be seen as a tree. The view in Blueriq on the left side is called the Tree View, see an example on the right. Whether a document was created using the RTF import wizard or a document is modeled from scratch it is advised to think about the intended structure and styles before starting or modifying (in case a document was imported).

 

 

 

Define the smallest unit

Before you start modelling define the smallest unit. A unit most likely will be either a word, sentence or paragraph. Hence, it is possible to form a sentence over multiple nodes adding conditions on parts of the sentence, example:

 

 

 

Could This structure could be the corresponding tree with a sentence "The <2a>applicant</2a><2b>applicants</2b> are required to provide all necessary papers", with a precondition on node 2a and 2b dependent of the number of applicants.

This could also be achieved by creating a node with one sentence and apply conditions within the sentence by selecting a part and click the 'add condition' button. However, in complex documents with many conditions on phrases and when using the specification method to encode a specification document breaking up the document in small units could be very helpful as the nodes could be named after the code or tag in the specification document.

 

Tree models

 

A document model can be seen as a tree with different types of nodes. Some of these nodes depict which child elements are allowed. For instance, the content style Table can be applied on a node. Consequently child elements may only have few types of content styles (for example TableRow). These settings can be changed in the Global Element of the content style.

Default a document tree model contains the following content styles determining the structure:

Paper type (Normal/Letter/Column)

Header(s) (-First/-Last)

<content>

Body

<content>

Footer(s) (-First/-Last)

<content>

Within one document the structure above can occur one or more times, for example in case of appendices or a cover letter. 

Note

Always include the content style Body. Without a Body the document will be empty.

In the example above the root node has a content style of either Normal, Letter or Column. These three styles are out of the box styles and can be used directly. Please have look at the print space examples in the previous part for examples of a Normal and Letter style. The style Column will divide the document into 2 columns by default, these and other settings can be changed in the style sheets (xsl files) for the style Column as for Normal and Letter or (custom) develop a style corresponding to the corporate branding. Recall that these three styles say something about the structure and margins, but not necessarily about colors or fonts.

The global elements of these content style depict what styles are allowed as child elements.  

Note

In a document (as opposed to a content item) styles applied on the root node will be ignored. Apply content styles starting from the second node being a child of the root node.

Reuse

  • Break up in content items for search and version control
  • Reuse components (content items), e.g. adressblock, footer, header, salutation, contact info, signature, paragraph, table, whole letter as cover for another document,
  • Split content and layout

Logic and style

  • Use Heading and HeadingTitle
  • Use repeat conditions
  • Logic in Blueriq, not in Document (reusable expressions, maintainable, TODAY, copy of information in application)
  • Naming nodes
  • Use empty nodes if necessary to create structure
  • Use nesting for readable maintainable documents

Other

  • Program errors explicitly

 

Panel
Section
Column

Previous: 2. Preparing a Documents solution