cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: Calculated fields
Date Mon, 10 Apr 2006 21:43:33 GMT
Simone Gianni wrote:
> 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.

That's why using event listeners is the way to go : the readFromRequest
phase buffers all events and actually sends them only once all widgets
have read their values from the request. This allows the form model to
be globally consistent when event listeners are called.

> 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?

You need to set a flag when a trigger widget has changed, and do the
actual recalculation when all events have been fired. I don't remember
if there's an associated phase change event that could be used for that.

There's a potential problem though if a trigger widget is itself
calculated. Or calculated fields must explicitly call the calculate()
methods of their trigger widgets that are calculated.

>>> 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? :)

Flexibility Syndrome, i.e. over-design or YAGNI (you ain't gonna need
it). I don't see the use case for it.

>>> 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.
>>> WDYT?
>> 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.

I wasn't speaking of the client side, but only about the increased
complexity of the form definition. This adds a new widget type (not that
much a problem) and more expression languages...


Sylvain Wallez
Apache Software Foundation Member

View raw message