Pre-parsed toView representation, which still knows the toData section
a given rule originated from. This allows to handle toView mappings from
the same toData element (from default and custom config) in a different
way, then those, which exist in parallel, i.e., those, which were
created by different toData nodes.
The suggested approach is to merge mappings originating from the same
toData elements hierarchically, while those from different toData nodes
will be merged sequentially. Or, from the perspective of the rules: For
hierarchical rules, a rule can block the other (parent), while in sequential
execution they all exist with the same priority in parallel.
The mapping is as follows:
toView key (i.e., data element to transform)
toData key (i.e., original toData section)
A special key " " (single whitespace) is used for those toView
mappings, where no corresponding toData mapping exists.
Pre-parsed
toView
representation, which still knows thetoData
section a given rule originated from. This allows to handletoView
mappings from the sametoData
element (from default and custom config) in a different way, then those, which exist in parallel, i.e., those, which were created by differenttoData
nodes.The suggested approach is to merge mappings originating from the same
toData
elements hierarchically, while those from differenttoData
nodes will be merged sequentially. Or, from the perspective of the rules: For hierarchical rules, a rule can block the other (parent), while in sequential execution they all exist with the same priority in parallel.The mapping is as follows:
toView
key (i.e., data element to transform)toData
key (i.e., originaltoData
section)A special key
" "
(single whitespace) is used for thosetoView
mappings, where no correspondingtoData
mapping exists.