Re: wicket 1.5 ajax replace and jquery memory leak

2013-01-14 Thread Ernesto Reinaldo Barreiro
Hi,

On Mon, Jan 14, 2013 at 4:23 PM, Ernesto Reinaldo Barreiro <
reier...@gmail.com> wrote:

> Hi,
>
> On Mon, Jan 14, 2013 at 4:13 PM, Sven Meier  wrote:
>
>> Thanks Martin,
>>
>> I was afraid of that answer ;).
>>
>> @wiquery-devs:
>> Does wiquery help here or do I have to roll my own monkey-patch?
>>
>>
> AFAIK there is nothing on wiquery to fix that...  but I might be wrong.
>
> By the way... I have found a similar issue on YUI based date picker
> of wicket-datetime extension. E.g. date pickers created in a repeater are
> not removed from "YAHOO.wicket" object (on client) and this object grows
> and grows and date pickers creation  becomes slower and slower  (at least
> on 1.4.x). I had to fix that for a client using 1.4.x... Let e see if I can
> create a quickstart illustrating this (for 6.x).
>
>
https://issues.apache.org/jira/browse/WICKET-4975

-- 
Regards - Ernesto Reinaldo Barreiro
Antilia Soft
http://antiliasoft.com/ 


Re: wicket 1.5 ajax replace and jquery memory leak

2013-01-14 Thread Ernesto Reinaldo Barreiro
Hi,

On Mon, Jan 14, 2013 at 4:13 PM, Sven Meier  wrote:

> Thanks Martin,
>
> I was afraid of that answer ;).
>
> @wiquery-devs:
> Does wiquery help here or do I have to roll my own monkey-patch?
>
>
AFAIK there is nothing on wiquery to fix that...  but I might be wrong.

By the way... I have found a similar issue on YUI based date picker
of wicket-datetime extension. E.g. date pickers created in a repeater are
not removed from "YAHOO.wicket" object (on client) and this object grows
and grows and date pickers creation  becomes slower and slower  (at least
on 1.4.x). I had to fix that for a client using 1.4.x... Let e see if I can
create a quickstart illustrating this (for 6.x).



> 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  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: 
> users-unsubscribe@wicket.**apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


-- 
Regards - Ernesto Reinaldo Barreiro
Antilia Soft
http://antiliasoft.com/ 


Re: wicket 1.5 ajax replace and jquery memory leak

2013-01-14 Thread Sven Meier

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  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: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org



Re: wicket 1.5 ajax replace and jquery memory leak

2013-01-14 Thread Martin Grigorov
Hi Sven,


On Mon, Jan 14, 2013 at 3:23 PM, Sven Meier  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
>



-- 
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com 


wicket 1.5 ajax replace and jquery memory leak

2013-01-14 Thread Sven Meier

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?

- Or isn't this a problem at all?

Thanks
Sven