Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 53735 invoked from network); 10 Apr 2006 12:38:51 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 10 Apr 2006 12:38:51 -0000 Received: (qmail 88867 invoked by uid 500); 10 Apr 2006 12:38:48 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 88804 invoked by uid 500); 10 Apr 2006 12:38:48 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 88790 invoked by uid 99); 10 Apr 2006 12:38:48 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Apr 2006 05:38:48 -0700 X-ASF-Spam-Status: No, hits=0.9 required=10.0 tests=HTML_10_20,HTML_MESSAGE X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: local policy) Received: from [195.225.171.136] (HELO localhost) (195.225.171.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 10 Apr 2006 05:38:46 -0700 Received: (qmail 19417 invoked from network); 10 Apr 2006 14:30:01 +0200 Received: from 85-18-136-98.fastres.net (HELO ?192.168.0.9?) (s.gianni@thebug.it@85.18.136.98) by 195.225.171.136 with AES256-SHA encrypted SMTP; 10 Apr 2006 14:30:01 +0200 Message-ID: <443A51BA.6010109@thebug.it> Date: Mon, 10 Apr 2006 14:38:18 +0200 From: Simone Gianni User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050807) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Calculated fields References: <44393403.8000403@thebug.it> <443A2F61.80200@apache.org> In-Reply-To: <443A2F61.80200@apache.org> Content-Type: multipart/alternative; boundary="------------080905000906080002090904" X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N This is a multi-part message in MIME format. --------------080905000906080002090904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 --------------080905000906080002090904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
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
--------------080905000906080002090904--