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 12:38:18 GMT

Sylvain Wallez wrote:

>>My calculated field prototype calls algorithm.calculate() in
>>readFromRequest(). Is there a better place?
>There's a problem to compute the initial value, as trigger widgets may
>not be initialized (or a calculated-field's initialize() can call
>initialize() on the widgets it depends on).
>>From there on, you should only react to change events from trigger widgets.
Yep, I'm just afraid to perform calculations more than once in a single 
update. Since i already have a javascript algorithm, I'm afraid of the 
possible overhead. The trigger widgets currently set a "recalculate" 
flag, and in readFromRequest() i actually perform this :

- Call super.readFromRequest().
- If super.readFromRequest() parses a typed value, then the field goes 
in "user typed" mode and does not perform any calculation.
- Else checks if the recalculate flag is set.
- In that case call the algorithm.

Obviusly this poses the following problem : "What if the 
readFromRequest() is called for the calculate field before the 
readFromRequest() has been called on triggers?". In that case the 
following could occurr :
- The algorithm would either fail due to a null value or similar.
- The algorithm would return a non update value.

I tried a fallback for the first situation, when the algorithm cannot 
compute a value. In that case the algorithm is again called when a 
trigger notifies a value changed event, but this is untidy and also have 
no way to handle the second situation.

Maybe it would be easier to install a ProcessingPhaseListener, using it 
this way :
- I receive value changed notifications from triggers, and set the flag.
- In readFromRequest i only check if the user typed something or not.
- When the form notifies it has finished parsing values (and validating 
them) :
... check if the recalculate flag is set
... in that case call the algorithm
... clear the recalculate flag
- Also, since an algorithm may also need values from other calculated fields
... in getValue(), if the recalculate flag is set, call the algorithm.
... also use a calcualting flag, to report an error if a circular 
calculation is detected.

Using the ProcessingPhaseListener is a better solution? WDYT?

>>I'm also trying to make them editable (if editable="true" specified in
>>the definition), so that if the user wants to "fine tune" the result
>>of a calculation he can modify the calculated value. Obviously, once
>>the calculated field has been modified by the user it will behave like
>>a common field, maybe until the user erases the value bringing the
>>field back to it's calculated nature?
>Yikes! Heavy FS smell!
FS? Fun Stuff? Free Style? Fiancial Service? :)

>>I tried something to make them also client side, but I don't think
>>it's a good idea. With such a good AJAX support, client side support
>>is rarely useful. Also, it poses a lot of limitations and a lot more
>>work on it : all algorithms should be able to generate a client side
>>counterpart, triggers should be rendered as client side calls to
>>"calculateXXX" functions. There is no tidy way to do this, and some
>>algorithms would be very difficult to port client side. Also, on
>>client side there is no way of apply proper field formatting, so every
>>form using calculated fields with a format different from plain will
>>end up being a mess.
>This adds more complexity to CForms. But if people consider it useful,
>well, why not.
-1 for client side. As i wrote, it brings A LOT of complexity, for 
formatting, double implementation of everything (algorithm must be wrote 
both for server side and for client side, both for us and for the user), 
a lot of untidy stuff needed to do it, and it's relatively useless with 
current great AJAX support. I think it was written in the Jira issue 
because at that time Ajax was still far.


Simone Gianni

View raw message