Okay I pushed a new diff.
This is an example in-production. The criteria to sort the entries in this case is a resolved flex-field "field_start" and thus unavailable to the ordering available by select{}. The 'orderObj' is basically a parallel alternative /view/ of the 'renderObj' with the difference that its produced content is taken for sorting instead of display.
10 = CONTENT
10.source.current = 1
10 {
table = tt_content
select {
pidInList = 26
where = tx_templavoila_to IN(1)
}
orderMax = 5
orderObj = USER
orderObj {
userFunc = tx_bestgetflexfield_pi1->getFieldValue
dbField = tx_templavoila_flex
flexField = field_start
}
renderObj = COA
renderObj {
10 < tt_content
}
}
This is just a simple example. Other uses may involve the calculation of values out of regular database entries through a different userFunc like:
orderObj.userFunc = calculateTax() {
if (field_is_not_ngo)
return field_price + tax[field_tax_class];
return field_price;
}
I just sketched it out, I hope it's clear.
And well these example are only covering USER, I may imagine very complex sorting-key construction through COA and/or INT-types where the ordering is based on random or time-dependent calculations.