views:

59

answers:

3

imagine that we have loaded a complex website with lots of Javascript which loaded all sort of info via AJAX and by making computations based on user input. So, now suppose we want to archive it in such a way that we can reliably load it later on from file (maybe even without an internet connection) and study its behavior / debug it / etc. Is there a way to do this?

A: 

Where would you want to store it?

Currently there's no way to store anything browser side (apart from new browser features, that very few people have installed). The only realistic solution would be in a Cookie if the DOM is small enough (this is because a Cookie can only hold a certain amount of data).

If you're looking at storing the DOM server-side, then you could use document.body.innerHTML to access the current DOM state and then send it to your server.

Luca Matteis
That's not true. Look at Google Gears, or the new features in Firefox 3.5.
SLaks
“Currently there's no way to store anything browser side.” You might want to read up on HTML5 `localStorage`.
Mathias Bynens
Sure, but it's not used enough to work for any realistic application.
Luca Matteis
Actually using local storage has been possible for some years already - virtually every major browser supports it one way or another. I have written a small wrapper library for firefox/ie/safari to accomplish this. http://www.domcached.com/
Andris
@Andris, how portable is this? I just tested it on my Chrome, and it doesn't work.
Luca Matteis
Also, you might wan to tell us about what Storage Techniques you've used, just answer the main question.
Luca Matteis
@Luca Matteis - Chrome 3 doesn't support local storage but Chrome 4 beta supports both HTML5 localStorage and WebKit database storage (SQLite). The SQLite beats localStorage hands down but as it is currently only available on WebKit then it's not much use
Andris
`innerHTML` wont capture the altered values for any `input` elements
Justin Johnson
@Justin, sure it will, just use `defaultValue`
Luca Matteis
+2  A: 

The browsers already do this to make the "Back" button work fast -- in Firefox it's called "bfcache". This cache lives only in memory, though. I don't know if it's possible to serialize it to a file, if yes, it would be very interesting.

Nickolay
+1  A: 

I don't think there's a way to export the entire DOM state without manually looking at each piece, and storing it. There is a lot of information that goes in representing that DOM than what visible in the source.

For instance, you might want to save the window scrollbar position which is available in the window object as window.scrollX and window.scrollY. This is just one example but there's plenty of other state information to be saved including attached event handlers etc.

If you could identify the pieces that are relevant for you purposes while ignoring others, you could store it locally using Google Gears (now obsolete) or the new Local Storage introduced in HTML5 and if you are already serializing this information, you could pass it on to some server and restore it from there. The new storage mechanism in HTML5 is called DOM Storage but its a little misleading because it's just a key value pair storage where both the keys and values are strings.

Edit: This might be a different perspective on the problem but here it goes. Instead of storing the entire DOM state, you could store just the intial state, and the relevant actions that change it. To get to the final state, a replay mechanism would be used that runs each action in sequence. This is a popular design pattern known as the Command pattern. That's how multiplayer games keep each player up-to-date and in-sync by passing only the player actions like a keystroke, mouse movement, etc. instead of the entire view and the receiver applies those actions to update its state. It's a lot more complicated than that in practice but thats the crux of it.

Anurag