First off: great idea!
Antonio Gallardo said the following on 10-04-2006 02:46:
What about replacing <fd:algorithm> with something like:
<fd:value eval="items*price"/>
<fd:value eval="sum(articles.items)"/>
this will allow also to write:
<fd:value eval="sum(articles.items*articles.price)"/>
<fd:value eval="sum(articles.subtotal)"/>
In both later cases, <fd:value> should be able to know that "articles"
is a container and hence it needs to include in the operation the whole
set of rows from the repeater.
I think we should first define the user interface and then go into
implementation details.
I agree with Antonio that the syntax should be more flexible than your
initial proposal. I actually had a use case that required even more
elaborate calculation:
The score is the sum of a number of fields (not part of a repeater) only
if all of the fields are set to a value. Example:
Field1, Field2, Field3: each have a range 0..3
TotalScore =
if (empty(Field1) || empty(Field2) || empty(Field3)) {
sum(Field1, Field2, Field3)
}
else {
"score undefined"
}
So two additions:
- use calculated fields for all widgets, rather than just repeaters
- allow a more flexible way of expressing the calculation, maybe a
user-defined class of Expression or Algorithm.
Some random thoughts:
- use Antonio's suggestion for simple expressions
<fd:calculatedfield id="total" ....>
....
<fd:value eval="field1*0.5"/>
....
</fd:calculatedfield>
- allow a javascript function or java class to handle the expression:
<fd:calculatedfield id="somecalculation" ....>
....
<fd:value params="{field1, field2, field3}"
function="myjavascriptfunction"/>
....
</fd:calculatedfield>
or
<fd:calculatedfield id="othercalculation" ....>
....
<fd:value params="all" function="javamethod"/>
....
</fd:calculatedfield>
I don't have the proper syntax available here, but the last two could be
done in much the same way as the <fd:value-changed> syntax.
Bye, Helma
