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.
**Compatibility**
This feature can be implemented in a way is not fully compatible with the current behavior. approach.
# Currently only one special column columns (except @_nowrap@ and @_hide@) is allowed and they are expected to be listed as first. These columns first, but they only affect the rendered content and not the value.
#* For a compatible behavior the value @{{colname:R}}@ must This may not be always the initial value, whereas desired behavior: the rendered value is @{{&colname:R}}@.
#* A more natural behavior would be to make @{{colname:R}}@ encrypted by @_encrypt@ or the _rendered value_. How much would break with this change?
#* Note that @{{&colname:R}}@ is obsolete as the same value can token generated by @_jwt@ cannot be obtained with @{{colname.out:R}}@. Removing @&@-values breaks compatibility. stored currently in a variable.
# The behavior of @_hide@ and @_nowrap@ is unchanged - these processors are not expected to change the value of the column.
Notes:
# A mixed * In case the current behavior can be implemented with is expected, this feature must implement a special command way to set mark a report to be processed in the parsing new or in the legacy mode. For now the legacy mode (legacy should be the default one for backwards compatibility.
* The new mode can be automatically turned on when a new syntax is used, such as aliases or new). columns with parameters, unless these features are released earlier.
* Another option is to modify only the value of @{{&<variable>:R}}@.