Platinum sponsors
1.9. using stdWrap correctly
The function stdWrap includes a wide variety of functions and parameter. Some are trivial, the use of some are hard to find. Here we will commit ourselves to the basic principle and highlight a few special functions/properties.
The stdWrap-property can only be used if its defined explicitly. If we have a property of type "wrap" then there are no stdWrap-properties. By default either a property of type stdWrap is presented or a property offers for example "string/stdWrap".
10 = IMAGE
10.stdWrap.typolink...
The object has a property stdWrap of type stdWrap.
10 = HTML
10.value = Hello World
10.value.typolink …
The object HTML in contrast has a property of type string/stdWrap. We can add a string and in addition we can use stdWrap properties.
An important limitation should be highlighted:
The single functions are executed in the order specified by the reference
If we don't pay attention to this fact the results might look different from what we expected.
10 = TEXT
10.value = Hello World
10.case = upper
10.field = header # assuming the header contains “typo3” (small case characters)
10.stdWrap.wrap = <strong>|</strong>
# results in the following:
<STRONG>TYPO3</STRONG>
The following happens in this example: First the value of the TEXT-object is set to "Hello world". We know that the TypoScript configuration is stored in an array. The sorting in this array is not like the sorting in TypoScript. The sorting in the array is constrained by definitions of the ordering of stdWrap. This order is mirrored by the reference. After a short look into the TSRef it should be clear that first “field” is processed, thereafter stdWrap (and with it “stdWrap.wrap”) and in the end “case”.
use stdWrap recursively
Because the stdWrap function can be called recursively it is possible to change the execution order.
The function "prioriCalc" permits easy mathematical expressions. If set to 1 the content is calculated - however the calculations are done from left to right (no mathematical precedence like "*" before "+" etc.). The following example looks as if the content of field "width" get 20 added to it.
10 = TEXT
10.field = width # Assumption: "width" is 100
10.wrap = |+20
10.prioriCalc = 1
This is not the case. The result which will be rendered is: "100+20". The function "prioriCalc" is executed before the function wrap is executed and thus only calculates the result of "field" the expression "100". In order to get the result we anticipated we have to make sure that "field" and "wrap" are executed before "prioriCalc" is executed. This can be achieved by using the following expression:
10.stdWrap.wrap = |+20
The stdWrap function will be executed after "field" but before "prioriCalc" thus "100+20" is wrapped and after that the function "prioriCalc" is executed resulting in the value "120".
Whilst typoScripting its crucial to know what kind of datatype we are handling. Especially with stdWrap we noticed its becoming common practice to combine functions arbitrarily until the anticipated result is achieved by accident.
Only if the stdWrap functionality is mentioned explicitly, the stdWrap functions like field, data or typolink can be used.
stdWrap offers a property "lang" with which it is possible to translate simple texts which are implemented via TypoScript on a page.
10 = TEXT
10.value = Imprint
10.lang.de = Impressum
10.typolink.parameter = 10
However text like these are hard to translate by external editors. Especially with unknown languages this can become a challenge.
For this case it is best to handle the translations with constants. These can be placed together at a specific place and implemented into TypoScript.
# Constants
text.imprint = Imprint
text.de.imprint = Impressum
# Setup
10 = TEXT
10.value = {$text.imprint} 10.lang.en = {$text.en.imprint}10.typolink.parameter = 10
This way the translation is not depending on the TS configuration of the item.
