|
<< Click to Display Table of Contents >> Template texts |
Commonly formulations in the Description field in the operation rows, are suitably handled as template texts.
Advantages:
•Reduced keyboard typing.
•Reduced risk for typos.
•Possibility to retrieve identities directly from the network documentation.
•Possibility to advanced layouts including read only fields.
•Possibility to mirror operation rows that are customer specific.
•Uniform formulations.
All the template texts are handled in the Codelist manager. See section General resources for authorizations, start and updating the server. Select the Codelist owner - Operator (OPERATOR). Select the Codelist OPERATION_ORDER_ROW_DESC_CL.
This codelist works in the same way as every other codelists. It is possible to edit and uncheck that a text should no longer be active and therefore not will be visible in the list of template texts.
Note! The column COUNTER_DESCRIPTION, where it is possible to map a counter operation that will be used when the point of operation is mirrored.
As any other central information in the Operating order module, current operating orders are not affected by later changes in the template texts. The handling of the template texts follows the standard and it is hence not possible to remove a text by using the tool - enter zero in the field Active value/ACTIVE instead.
It is possible to mix static texts with input fields for dynamic content.
Example 1 |
1.The template text is "Enter your own text here @{1}". 2.When the list with template texts are opened from the operation row, it is the same as has been entered. See above. 3.When the text is selected, a new dialog window is opened and the @{1} is displayed as an input field according to the image below. |
Example 2 |
1.The template text is "Select station in the map and insert it here @{1:station}". 2.When the list with template texts are opened from the operation row, it looks the same as has been entered. See above. 3.When the text is selected, a new dialog window is opened and the @{1} is displayed as an input field with the possibility to retrieve texts from the map/schema. |
Further fields are added with @{2}, @{3} ... @{n}.
If a dynamic value should be used twice in the same text, it is possible to use @{1} (etc.) in two places in the template text.
Line identities/cable numbers can be retrieved if, @{1:station} is replaced by @{1:cable}.
You can create complex template texts / tags with HTML tags. Knowledge of HTML is required for this, but it is, of course, possible to order the template definitions from Digpro as well.
Complex template texts are mainly used to meet two needs:
•Layout in the style of traditional labels for evidence exchange with fields and dividing lines.
•Fields that must be writable in specific states - during editing, during execution or a combination of these.
These two needs often coincide.
These template texts are entered the same way as other template texts via Administration > Codelist manager > Operator > Operation_order_row_desc_cl.
Note that HTML-based templates should not be used in other template texts (such as "description_cl or operation_order_permit_desc_cl").
Complex template texts support (of course) only a limited subset of the HTML standard. Although it "works", for example, defining a particular font or hard-coded text size, this is generally advised against. The result may not be as desired, for example in PDF or on a 4K screen.
Examples of recommended tags are:
•Tables, rows and cells (for layout of labels).
•Relative text sizes (that is, relatively larger / smaller than standard rather than an absolute text size).
•Colors (usually to mark input fields in the template).
•dpSpatial's own classes to define fields possible to type in.
dpSpatial's own classes to define in which states a field should be possible to type in are based on the head-section in the HTML code containing the text data-dptemplate-version = "2". To see the input fields, definition is also recommended in a style block - for example <style> .editable {background-color: # c0c0c0;} </style>. Finally, the field itself must be tagged in the code. This can be accomplished in several ways. One method is to put a span block around the part of the text that forms the input field (… static text <span class = "editable"> __ </span> more static text ...). Note that there are some placeholder characters in the span block, so that the field is visible in the application. If this feels too complicated, it is probably easier to study the examples.
Note that template texts, defined before version 8.6, may need to be adjusted to be possible to update in desired states. As of 8.6, the following classes apply:
•Editable - fields that are writable Under preparation, For completion and Under revision.
•Editable-perform – fields that are writable in state Executing.
•Editable-active – fields that are writable in all the above states and Approved.
If the template text is to be used with Operator in dpWebmap, the following must be considered.
The entire page in dpWebmap is based on HTML. Therefore, style definitions (<style> -tags) for cells in the operations/operation rows may interfere with each other. If the HTML templates are to be used in dpWebmap and style attributes are defined, these must be defined immediately in each templates <body> and not as an overall style definition. See example 3 below.
Example 1 - a simple text with an input field that should be writable while the operating order is executed:
"Detta fält (_) ska vara skrivbart, medan resten av texten är skrivskyddad.

A very simple example that does about the same thing as… {@ 1}… had done without HTML
<html>
<head data-dptemplate-version="2">
<style>.editable{background-color:#e0e0ff;}</style>
</head>
<body>Detta fält <span class="editable">__</span> ska vara skrivbart, medan resten av texten är skrivskyddad.</body>
</html>
Note that this example is simplified to focus on the essentials. In a real case, it is recommended to use a table definition around the text, see example 2.
Example 2 - HTML definition for permit exchange:

Stylized exchange of permit- acid-colored fields are writable during editing, pistachio-colored fields are writable during execution, while the yellow field is writable in all active states.
<html>
<head data-dptemplate-version="3"><style>.editable {background-color:#e0e0ff;} .editable-perform{background-color:#e0ffe0;} .editable-active{background-color:#ffff80;}</style>
</head>
<body>
<p style="margin-top:0"><font size="5">Bevisväxling</p>
<table border="0" width="100%">
<tr>
<td colspan="2" border="1">Bevis utväxlat för <span class="editable">__</span> i <span class="editable">__</span></td>
</tr>
<tr>
<td colspan="2" border="1">Kommentar: <span class="editable-active">__</span></td>
</tr>
<tr>
<td border="1">Från, signatur: <span class="editable-perform">__</span> tid: <span class="editable-perform">__</span></td>
<td border="1">Till, signatur: <span class="editable-perform">__</span> tid: <span class="editable-perform">__</span></td>
</tr>
</table>
</body>
</html>
Example 3 – template compatible with dpWebmap
<html>
<head data-dptemplate-version="3">
<style>
.submit-date {background-color:# d4f4f4;}
</style>
</head>
<body>
<p>template that <em>may interfere</em> with other templates<br>
Utlämnad, date: <span class="submit-date">_____</span>
</p>
</body>
</html>
This template risks conflicting with other templates that use the same style definition.
<html>
<head data-dptemplate-version="3">
</head>
<body>
<p>template that <em>work</em> with other templates<br>
Utlämnad, time: <span class="submit-time" style="backgroundcolor:# d4f4f4;">_____</span>
</p>
</body>
</html>
This template should not conflict with other templates style definition.
The template texts that are used inside a label (see section Text template) are located in its own codelist.
See section Static template texts for general information about the Codelist manager. Change the codelist OPERATION_ORDER_ROW_DESC_CL to OPERATOR_ORDER_PERMIT_CL. Otherwise the handling is more or less identical (for natural reasons counter operations are not handled for example).
The fields Operational state, other and Other in the tab prerequisites have a common codelist. See section Static template texts for general information about the Codelist manager. Change the codelist OPERATION_ORDER_ROW_DESC_CL to DESCRIPTION_CL. Otherwise the functions are similar.