By default the prototype.js gives us the function /* prevent memory leaks in IE */ Event.observe(window, ''unload'', Event.unloadCache, false); But there is no unload event in out application as the content of the div keeps changing using the Ajax.Updater function. To handle such a scenario, we''ve added the following lines of code to prototype.js /* prevent memory leaks in IE */ Event.observe(window, ''unload'', Event.unloadCache, false); Event.observe(document, ''readystatechange'', Event.unloadCache, false); Now I''m still testing and will proceed with it, but would like to know will this help in improving the performance, if not, then what is the optimum way to use this function to clean & clear the IE memory as the page get''s refreshed. Regards Varun Mehta *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* imagination is more important than knowledge - albert einstein *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* Visit Varun at * <http://varun.cjb.net/> http://varun.cjb.net [HTML] * <http://varuninfo.cjb.net/> http://varuninfo.cjb.net [Blogged] * <http://varunmehta.cjb.net/> http://varunmehta.cjb.net [Flash] _______________________________________________ Rails-spinoffs mailing list Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
Yikes.... That''s ok if you only ever have ONE div that gets updated.
But
what about when you start getting into truly autonomous widgets? What I
mean is, having dozens of controls on a page, each responsible for their
own communication with the server, each with their own div that they
update. Or if you want an ajax widget nested inside another one, where
when the inner one needs to update, you don''t necessarily need or want
the outer one to update?
Your method is fine if none of those scenarios are a concern for you. If
they could be down the road, then what you should do is create dispose()
method for each of your objects that handles clearing out all of its
event handlers before sending the request to be updated.
So a pseudo-object would look like...
someObject.prototype
{
initialize: function()
{
this._attachEvents();
...other initialization code...
},
_attachEvents: function()
{
this.someClickListener
this.someElement_Clicked.bindAsEventListener(this);
Event.observe($("someElement"),
"click",
this.someClickListener);
...attach other DOM event handlers here (always
assign to variables for future reference and cleanup)
},
_detachEvents: function()
{
Event.stopObserving($("someElement"),
"click",
this.someClickListener);
this.someClickListener = null;
},
someElement_Clicked: function(event)
{
alert("clicked!");
},
dispose: function()
{
this._detachEvents();
...other cleanup code (like unregistering
droppables, draggables, calling dispose on children objects, etc..)
}
};
________________________________
From: rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
[mailto:rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org]
On Behalf Of Varun
Mehta
Sent: Wednesday, February 01, 2006 8:31 AM
To: rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
Subject: [Rails-spinoffs] IE memory fix leak.
By default the prototype.js gives us the function
/* prevent memory leaks in IE */
Event.observe(window, ''unload'', Event.unloadCache, false);
But there is no unload event in out application as the content of the
div keeps changing using the Ajax.Updater function. To handle such a
scenario, we''ve added the following lines of code to prototype.js
/* prevent memory leaks in IE */
Event.observe(window, ''unload'', Event.unloadCache, false);
Event.observe(document, ''readystatechange'', Event.unloadCache,
false);
Now I''m still testing and will proceed with it, but would like to know
will this help in improving the performance, if not, then what is the
optimum way to use this function to clean & clear the IE memory as the
page get''s refreshed.
Regards
Varun Mehta
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
imagination is more important than knowledge - albert einstein
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Visit Varun at
* http://varun.cjb.net <http://varun.cjb.net/> [HTML]
* http://varuninfo.cjb.net <http://varuninfo.cjb.net/> [Blogged]
* http://varunmehta.cjb.net <http://varunmehta.cjb.net/> [Flash]
The information transmitted in this electronic mail is intended only for the
person or entity to which it is addressed and may contain confidential,
proprietary, and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this information by persons or entities other than the intended recipient
is prohibited. If you received this in error, please contact the sender and
delete the material from all computers.
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
Thanks for the prompt reply!
The scenario is we are hitting an AJAX, refreshing a div and then
re-registering a Sortable. After calling the DIV 6-7 times, the dragables
start getting sluggish, and as we keep ajaxing it for 11- 12 times the page
is as good as dead, the dragables refuse to budge from their position.
We tried the
/* prevent memory leaks in IE */
Event.observe(window, ''unload'', Event.unloadCache, false);
Event.observe(document, ''readystatechange'', Event.unloadCache,
false);
But in vain, after some calls it fails again. We are using the 1.5.0_rc2,
cos the latest version 1.5.1 makes the application sluggish right from
beginning. I also tried replacing the Dragabbles code from the SVN trunk,
but of little use.
My main problem is to either remove the registered Sortables to clear the
memory and then re-register, or get something tweaked in the library so it
does not deteriorate over time with ajaxing. The older versions seem to be
working better than the latest one.
Regards
Varun Mehta
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
imagination is more important than knowledge - albert einstein
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Visit Varun at
* http://varun.cjb.net <http://varun.cjb.net/> [HTML]
* http://varuninfo.cjb.net <http://varuninfo.cjb.net/> [Blogged]
* http://varunmehta.cjb.net <http://varunmehta.cjb.net/> [Flash]
_____
From: rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
[mailto:rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org]
On Behalf Of Ryan Gahl
Sent: Wednesday, February 01, 2006 8:14 PM
To: rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
Subject: RE: [Rails-spinoffs] IE memory fix leak.
Yikes.. That''s ok if you only ever have ONE div that gets updated. But
what
about when you start getting into truly autonomous widgets? What I mean is,
having dozens of controls on a page, each responsible for their own
communication with the server, each with their own div that they update. Or
if you want an ajax widget nested inside another one, where when the inner
one needs to update, you don''t necessarily need or want the outer one
to
update?
Your method is fine if none of those scenarios are a concern for you. If
they could be down the road, then what you should do is create dispose()
method for each of your objects that handles clearing out all of its event
handlers before sending the request to be updated.
So a pseudo-object would look like.
someObject.prototype
{
initialize: function()
{
this._attachEvents();
.other initialization code.
},
_attachEvents: function()
{
this.someClickListener
this.someElement_Clicked.bindAsEventListener(this);
Event.observe($("someElement"),
"click",
this.someClickListener);
.attach other DOM event handlers here (always assign
to variables for future reference and cleanup)
},
_detachEvents: function()
{
Event.stopObserving($("someElement"),
"click",
this.someClickListener);
this.someClickListener = null;
},
someElement_Clicked: function(event)
{
alert("clicked!");
},
dispose: function()
{
this._detachEvents();
.other cleanup code (like unregistering droppables,
draggables, calling dispose on children objects, etc..)
}
};
_____
From: rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
[mailto:rails-spinoffs-bounces-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org]
On Behalf Of Varun
Mehta
Sent: Wednesday, February 01, 2006 8:31 AM
To: rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
Subject: [Rails-spinoffs] IE memory fix leak.
By default the prototype.js gives us the function
/* prevent memory leaks in IE */
Event.observe(window, ''unload'', Event.unloadCache, false);
But there is no unload event in out application as the content of the div
keeps changing using the Ajax.Updater function. To handle such a scenario,
we''ve added the following lines of code to prototype.js
/* prevent memory leaks in IE */
Event.observe(window, ''unload'', Event.unloadCache, false);
Event.observe(document, ''readystatechange'', Event.unloadCache,
false);
Now I''m still testing and will proceed with it, but would like to know
will
this help in improving the performance, if not, then what is the optimum way
to use this function to clean & clear the IE memory as the page
get''s
refreshed.
Regards
Varun Mehta
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
imagination is more important than knowledge - albert einstein
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
Visit Varun at
* <http://varun.cjb.net/> http://varun.cjb.net [HTML]
* <http://varuninfo.cjb.net/> http://varuninfo.cjb.net [Blogged]
* <http://varunmehta.cjb.net/> http://varunmehta.cjb.net [Flash]
_____
The information transmitted in this electronic mail is intended only for the
person or entity to which it is addressed and may contain confidential,
proprietary, and/or privileged material. Any review, retransmission,
dissemination or other use of, or taking of any action in reliance upon,
this information by persons or entities other than the intended recipient is
prohibited. If you received this in error, please contact the sender and
delete the material from all computers.
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs