Feature #17295
Updated by Krzysztof Putyra 8 months ago
The syntax
<pre> <value> AS 'col1|col2|col3' </pre>
can represent a processing queue of @value@ by three processors with the output of last one taken as the column value. In this example the process queue is
<pre>
+------+ +------+ +------+
<value> -->--| col1 |-->--| col2 |-->--| col3 |-->-- <processed>
+------+ +------+ +------+
</pre>
A column processor may populate more values into a store, that are accessed using the notation @<colname>.<property>@. Standard properties include
* @in@ - the value that the processor has received
* @out@ - the output of the processor (the rendered input)
Processors of special columns can add more properties. For instance, @link@ can populate @url@, @tooltip@, @text@, etc.
_Should the values be inherited by following processors? For instance, with the column name @_link|myvar@ should @{{myvar.url:R}}@ be defined?_
Notes:
* a column name that do not begin with an underscore is processed by the default processor that saves the value in the R-store and forwards it to the next processor
* a column name @_<name>@ that is not a special column name is semantically equal to @_hide|<name>@
**Example 1**
<pre>
10.sql=SELECT 'Hello world!' AS 'plain|_encrypt|encrypted|_hide'
10.10.sql=SELECT 'Plain text: {{plain:R}}<br>Encrypted text: {{encrypted:R}}'
</pre>
produces
<pre>
Plain text: Hello world!
Encrypted text: <encrypted>
</pre>
**Example 2**
<pre>
10.sql=SELECT 'Hello world!' AS message|_+p
20.sql=SELECT '{{message:R}}'
</pre>
produces
<pre>
<p>Hello world!</p>
Hello world!
</pre>
**Example 3**
<pre>
10.head=<ul>
10.tail=</ul>
10.sql=SELECT url FROM Link
10.10.sql=SELECT 'u:{{url:R}}|c:nicelink' AS '_link|_+li'
</pre>
wraps links into @li@ elements. This example does not work currently, because it is not allowed to specify more than one special column.
**Example 4**
<pre>
10.head=<ul>
10.tail=</ul>
10.sql=SELECT encryptedValue AS '_decrypt|_+li' FROM data
</pre>
displays a list of decrypted values.
**Compatibility**
This feature can be implemented in a way compatible with the current behavior.
# Currently only one special column (except @_nowrap@ and @_hide@) is allowed and they are expected to be listed as first. These columns only affect the rendered content and not the value.
#* For a compatible behavior the value @{{colname:R}}@ must be always the initial value, whereas the rendered value is @{{&colname:R}}@.
#* A more natural behavior would be to make @{{colname:R}}@ the _rendered value_. How much would break with this change?
#* Note that @{{&colname:R}}@ is obsolete as the same value can be obtained with @{{colname.out:R}}@. Removing @&@-values breaks compatibility.
# The behavior of @_hide@ and @_nowrap@ is unchanged - these processors are not expected to change the value of the column.
# A mixed behavior can be implemented with a special command to set the parsing mode (legacy or new).