You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Jesse Kuhnert (JIRA)" <ta...@jakarta.apache.org> on 2006/11/03 00:06:18 UTC
[jira] Resolved: (TAPESTRY-1100) EventListener called several times
for a single form event if caching disabled
[ http://issues.apache.org/jira/browse/TAPESTRY-1100?page=all ]
Jesse Kuhnert resolved TAPESTRY-1100.
-------------------------------------
Resolution: Fixed
Ok...I finally saw this one and fixed it. Let me know if it keeps happening now..
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org