I've upgraded to the latest snapshot (today's morning snapshot), and I'm
afraid the bug is still there :-(
2006/10/17, Jesse Kuhnert (JIRA) <[email protected]>:
[ http://issues.apache.org/jira/browse/TAPESTRY-1100?page=all ]
Jesse Kuhnert resolved TAPESTRY-1100.
-------------------------------------
Fix Version/s: 4.1.1
Resolution: Fixed
This should be resolved in the latest snapshot. (i hope)
> EventListener called several times for a single form event if caching
disabled
>
------------------------------------------------------------------------------
>
> Key: TAPESTRY-1100
> URL: http://issues.apache.org/jira/browse/TAPESTRY-1100
> Project: Tapestry
> Issue Type: Bug
> Components: Core
> Affects Versions: 4.1.1
> Environment: tested under winXP SP2 + JDK1.5.0_07 + tomcat
5.5.17
> Reporter: Christian Dutaret
> Assigned To: Jesse Kuhnert
> Fix For: 4.1.1
>
> Attachments: taptest.zip
>
>
> I have a page with 2 @PropertySelection components (A and B). An
EventListener listens to onchange events on A, and changes the content of B
accordingly. When caching is enabled (-
Dorg.apache.tapestry.disable-caching=false), everything works as expected.
> On each onchange event, the dojo console indicates that the content of B
has been updated, and that a js script registering the onchange event has
been executed.
> If caching is disabled (-Dorg.apache.tapestry.disable-caching=true), the
behavior is different :
> - on the first onchange event, the listener is called once as expected
> - on the second onchange event, the listener is called twice
> - on the third onchange event, the listener is called four times.
> - etc
> Having a closer look at the dojo console output, it appears that the
form event registration script creates a different form event ID each time
the listener is called (when caching is enabled, the form event ID remains
the same). It seems that each response creates a new registration, instead
of overwriting the existing one. This would explain the observed behavior.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
