cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Gianni <>
Subject Re: Calculated fields
Date Mon, 10 Apr 2006 09:15:32 GMT
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 
- 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"/>

-- 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 type="custom" 
    or my custom language here.

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!

View raw message