Thanks Martin,
I was afraid of that answer ;).
@wiquery-devs:
Does wiquery help here or do I have to roll my own monkey-patch?
Thanks
Sven
On 01/14/2013 02:40 PM, Martin Grigorov wrote:
Hi Sven,
On Mon, Jan 14, 2013 at 3:23 PM, Sven Meier <[email protected]> wrote:
Hi all,
I'm investigating a browser memory leak in an application based on Wicket
1.4.
We're using jQuery event handlers (qtip) on rows in a Wicket dataTable.
Each time paging of the dataTable is changed through Ajax, the web page
leaks jQuery objects and DOM nodes.
I think the cause for this is when Wicket replaces DOM nodes as a result
of the Ajax call, the jQuery cache is not cleaned up.
The problem should be the same with Wicket 1.5. With Wicket 6 it is no
longer a problem, since now Wicket uses jQuery to alter the DOM tree and
jQuery keeps care of its cache automatically.
So my questions are:
- Did I miss something, is there some interoperability layer for Wicket
1.4/1.5 and jQuery to prevent this?
- As we're using wiquery, is there some magic feature to make Wicket use
jQuery's replace functionality?
This should be easy to try.
Contribute your own .js file *after* wicket-ajax.js that overrides (monkey
patches) Wicket.replaceOuterHtml() method and uses jQuery as
Wicket.DOM.replace() does in Wicket 6.x.
Wicket.replaceOuterHtml = function(element, newOuterHtml) {
var $newElement = jQuery(newOuterHtml);
jQuery(element).after($newElement).remove();
}
- Or isn't this a problem at all?
Thanks
Sven
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
