Ok… admittedly, this took me a while to look through…
Let’s see if I got this right - and perhaps this can help others, too:
Instead of hard-wiring the data structures in rules.mk to WATO pages, there can be a layer between both by using the
This class translates between the underlying data and their WATO representation.
forth = function for the representation in the frontend
back = function to store in the backend.
WATO --- back --> rules.mk
<-- forth --
I fiddled around with the rule “Citrix server load” which uses Transform and changed the forth and back lamdas as follows:
What happens now?
- Whatever rules.mk contains, the
forth lambda represents it in WATO as the tuple
- Whatever I enter in WATO, the
back lambda stores a tuple of
(2,22) in rules.mk.
Useless example, but the static values made it clear to my eyes
The (original) use case in the citrix rule is to let the user enter a number between 0 and 100 but store it as a float between 0 and 1 (
forth does the conversion in the opposite way.
As a conclusion, the abstract use case for
Transform is to store the data in some other way than the WATO page produces it.
I really like this concept because it finally answers the question why robotmk bakery rules always look like an accident:
So, having a Transform “forth” function which can read an older rule format can reduce the risk of existing rules becoming unreadable when the WATO page changes.
In the case of Robotmk where the WATO page changes again and again, it is perhaps useful to always store the current version number within the rule. After an update, the
forth function could then explicitly support migrations from an older major version to the current one.
I am leaving this open for discussion!