This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
The script demonstrate the differences very simply, but I'm having a little trouble making full sense the Mozilla link.
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.
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 ]