You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@wicket.apache.org by "Martin Grigorov (JIRA)" <ji...@apache.org> on 2011/06/09 17:06:59 UTC

[jira] [Updated] (WICKET-3782) Notifications before and after DOM node replacement

     [ https://issues.apache.org/jira/browse/WICKET-3782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Grigorov updated WICKET-3782:
------------------------------------

    Attachment: wicket-3782.patch

The proposed patch based on generic handlers registration.

Usage:
Wicket.Event.addEventListener(function() { 
  if (arguments[0] == "dom.node.removing") {        
     jQuery(arguments[1]).unbind();
  }
}

> Notifications before and after DOM node replacement 
> ----------------------------------------------------
>
>                 Key: WICKET-3782
>                 URL: https://issues.apache.org/jira/browse/WICKET-3782
>             Project: Wicket
>          Issue Type: New Feature
>          Components: wicket-core
>    Affects Versions: 1.5-RC4
>            Reporter: Martin Grigorov
>            Assignee: Martin Grigorov
>            Priority: Minor
>         Attachments: wicket-3782.patch
>
>
> Sometimes JavaScript libraries need to listen for some events on DOM nodes and they register their listeners. Later Wicket can replace such components (or their parent nodes) and the JavaScript listener will stop working.
> By adding notification before the replacement like 
> Wicket.DOM.callNodeChangeListeners('changing', element);
> and another one after:
> Wicket.DOM.callNodeChangeListeners('changed', newElement);
> where 'newElement' is the newly created element gives a chance to the JS library to react.
> The code above was my first attempt. Then I realized that custom JS events will be much better, but it appears IE doesn't support "unknown" events. There are workarounds like http://stackoverflow.com/questions/5342917/custom-events-in-ie-without-using-libraries but this code uses custom node traversal for event attaching as well which bothers me, I'm not sure what is the performance difference.
> So now I'm back on the approach with registered handlers but I think it will be better if it is made general. By passing the 'eventType' (like "wicket.dom.node.remove") as a parameter to the handler it may decide whether to react. Otherwise now we have pre/post/failure handlers for Ajax and who knows what else will be needed in the future.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira