Re: Calculated fields

[Simone Gianni]

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. 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. Simone -- Simone Gianni