Hi Antonio,
> <fd:value eval="sum(articles.items)"/>
...
> <fd:value eval="sum(articles.items*articles.price)"/>
...
> <fd:value eval="sum(articles.subtotal)"/>
This is a very nice syntax!! However this way we are binding the system
to a language. This creates a number of problems :
- What language is it? We should stick on xreporter expression not to
introduce a new syntax.
- AFAIK the current implementation of xreporter expressions does not
iterate.
- How do we provide expandibility of this language? If we don't we would
end up having users not being able to do what they want.
Maybe a good tradeoff could be :
-- Algorithms in xconf
<form-algorithms default="arithmetic">
<algorithm name="arithmetic" class="o.a.c.....Arithmetic"/>
<algorithm name="xreporter" class="o.a.c.....XReporter"/>
<algorithm name="javascript" class="o.a.c.....XReporter"/>
<algorithm name="custom" class="o.a.c.....CustomClass"/>
</form-algorithms>
-- Definition samples
<fd:value eval="sum(articles.items)"/> // Arithmetic
<fd:value type="xreporter" eval="Abs(a - b) + If(IsNull(c),d,c)"/>
<fd:value type="javascript">
var x = widget.getForm() ..... .. ..
// Javascript would be in the fd:value body, it would be a pain to
put it in an attribute
return result;
</fd:value>
<fd:value type="custom"
class="my.company.forms.algorithms.MyCustomAlgorithm">
<myCustomParameter>....</myCustomParameter>
or my custom language here.
</fd:value>
There could be some problems in "extracting" triggers from a javascript
or xreporter expression, if not preparsing them. So maybe a "triggers"
attribute where the user have to (read: can) specify which widgets
triggers recaulculation is needed for some algorithms.
> I think we should first define the user interface and then go into
> implementation details.
I do agree!
