Introduction¶
Templates for dotData questionnaires are a form of regular HTML intermixed with certain tags that tell the template where to insert the questions.
This section describes the structure, requirements and possibilities of the templating system.
Encoding¶
Templates should always be utf-8 encoded, both the encoding of the file itself when you upload it (check your text editor!) and the encoding of the HTML within:
<!doctype html>
<html>
<head>
<meta charset="utf-8" />
<meta name="robots" content="noindex">
<meta http-equiv="expires" content="tue, 01 jan 1980 1:00:00 GMT" />
<meta http-equiv="pragma" content="no-cache" />
<title>[# __title__ #]</title>
</head>
<body>
<form action="/dotdata/submit?sessionID=[# __sessionid__ #]" method="post" name="datainput">
[# __content__ #]
</form>
</body>
</html>
The form element is required and it needs to have the name ‘datainput’. The __content__ element inserts the actual instructions or question(s) into your html output.
Varying elements¶
At times you might want to vary elements of your templates without wanting to create a completely new element. For instance you might want a per- questionnaire title, or a per-endclient logo. To facilitate this, dotData has the ability to define dynamic elements in your templates as such:
[# CustomHTML('TheLogo') #]
This enables you to create your own dynamic elements. In the above example, it assumes you created within your questionnaire an element and you named it ‘TheLogo’.
Defining these elements is done in your project settings, under section ‘Layout template’. Elements are saved in xml format. When you click ‘builder’, you can edit the tags in a more handy format without knowledge of XML.
When an element is not defined in your project, the result will just insert an empty string, so nothing, at that location in your template.
Note
CustomHTML tags are strings that can have a limited length only. This mechanism is not meant to include huge blocks of texts or html.
Progress bar¶
Displaying a progess bar in a questionnaire can actually be quite cumbersome because it is not always clear with path the respondent will take through the routing of the questionnaire. Furthermore the respondent may skip significant parts of the questionnaire because of questions that are displayed conditionally.
When the ‘last page’ state is reached, the value of __progress__ will always be 100. The value of __progress__ always has a minimum of 1 even when there are so many items in your questionnaire it would round up to 0.
<script>
progress = [# __progress__ #]
...
Alternatively, if you want to manipulate the progress, you can calculate it in JavaScript:
<script>
progress = parseInt([# (min((__screensshown__ + __skippedscreens__) / __worstcasescreencount__, 1) * 100) #];
...
