Thanks Eric!
The script demonstrate the differences very simply, but I'm having a little trouble making full sense the Mozilla link.
1. This refers to just Mozilla's implementation of javascript, right? So something that causes leaks for Mozilla browsers might be safe for IE, and vice versa?
2. I understand that doing something like "myDiv.oref = new Array()" means the array can't be garbage collected as long as myDiv exists. But the headline "Don't store short-lived objects as JavaScript properties of short-lived DOM nodes" seems to imply that even if myDiv goes away (through either changing it's parent's innerHTML property or calling one of the removeNode() like methods), the array will be immunge to garbage collection?
I think it's best to give a brief overview of the project I'm working on and the strategies we're planning on using. At least I'll try to be brief. None of us are experts at Javascript, we've sort of been learning as we go.
The project is an intranet-only web-app for a specific customer. It is manadory that we support IE6.0, and while Firefox support would be nice, it's not part of the requirements.
The application is a "Contract Viewer." A user types in a contract number and sees the information regarding that Contract (retrieved from a database/repository.) There is a LOT of information there, so the contract view will have a collapsible tree-style navigation on the left, and "content view" on the right. Depending on what's selected from the navigation, the content view will either show a PDF document(inside an iframe) or tables and other information retrieved using XMLHttpRequest.
The user will be able to have multiple contracts open on the same page. Information regarding only a single contract will be viewable at a time, and the contracts will be switched between using "tabs". When a user opens a contract for the first time (during that session, on that page), XMLHttpRequest is used to get the HTML (navigation and the default content view) for that contract from the server. If there are no errors, a new "tab" is created on the page, and the contract is displayed by the setting of a DIV's innerHTML property to the retrieved HTML.
Now comes the question of how to keep track of the multiple contracts that a user has opened. We want to avoid going to the server every time the user switches between the already opened contracts by clicking on the different contract tabs. One solution would be to store each contract view in a seperate DIV element, and hide the DIVs for all non-selected contract tabs. The problem is that this would result in a HUGE Dom tree.
What we're planning to do is to have only a single DIV element for the contract data, and a javascript Array containing the innerHTMLs of every contract that's not being displayed. When a user is viewing a contract and opens a new one, the innerHTML of the contract DIV get's backed up in the Contracts Array, indexed by the currently displayed contract's number. Then the innerHTML gets replaced by the responseText of the XMLHttpRequest (new contract data). When a user clicks on a tab of a previously viewed contract, the DIV's innerHTML again gets backed up in the array, and is replaced by the innerHTML data that was stored in the array before.
This way instead of having a huge Dom tree for a page "displaying" multiple contracts, we have a huge javascript array. Actually each contract will have multiple possible "content views", selected from the navigation, which will act the same way - a user selects a certain view, XMLHttpRequest returns the HTML, the current view's innerHTML get's backed up in the contract's own array, and so on. So every entry in the big Contracts array will be a single Contract Array/object which will have the backed up innerHTML for the contract DIV, as well as the backed up innerHTMLs for each previously displayed content view for that contract.
The current plan is to only allow the user to have 6 contract's per page. If they want more, they will have the option to close one of the contract tabs. When a contract tab is closed, that contract's entry in the Contracts Array is set to null (ContractsArray[contractNumber] = null), which we hope will free up all the memory taken up by that contract's data.
I'm sorry if this is confusing, but I'm sure you can see why I'm worried about memory leaks with this setup. I know that most of these issues would be dealt with by only storing one contract's data in the page at a time and going to the server whenever a user clicks on a different contract tab, but we are trying to avoid it for server performance reasons. Plus we don't want the user's actions while on a contract's view (which navigation and content tree branches are expanded, which content view is selected) to be wiped during the switch, and keeping track of all that between requests would be a nightmare.
Thank you,
Yuriy
P.S. Good luck with your book! I'll be sure to get it when it comes out. And of course I understand that it takes priority
[ June 29, 2005: Message edited by: Yuriy Zilbergleyt ]