davepeck/appengine-go — pull request #5 by duncanexonsmith (2012-01-23 18:32:17+00:00)
Title: Added cache to the HistoryController

These commits add a cache to the `HistoryController` so that during a given history session, a given move is only retrieved once from the server.

- Speeds up interface when the connection is slow, and makes it possible in the future to load multiple moves at a time (preload).

- New classes `HistoryCacheItem` and `HistoryCache` do some of the work. I didn't spend much time designing the API, so these integrate with `HistoryController` in a somewhat ugly way... but the code should be clear enough.

- `HistoryCache` is fills an array with `HistoryCacheItem`s at initialization. I don't know JavaScript, so I wasn't sure how to check if an item was in the array (i.e., the equivalent to the python code: `move_number in this.items`); instead I fill the array at the start, but set an `is_cached` flag to `false`. If there's an `in` operator or something similar, that would probably be better.

- I changed `$("current_move_number")` to be updated immediately upon clicking next/previous/etc. This DOM element is kept in sync with a new variable, `history_controller.next_move_number`, which also updates immediately. `history_controller.current_move_number` is, as before, in sync with the move displayed on the board.

- This addresses some strange behaviour in the live version of the site when "next" is pressed multiple times in succession (faster than the connection can sustain).

- Assume you're at move 33 and press the "next" link 3 times quickly.

- Previously, it was possible update to move 35 and then, after a short wait, back to move 34.

- Now, the move should almost always be updated to move 36.

- When the `AjaxRequest` for a move returns, the board is only updated if the request is for the current value of `history_controller.next_move_number`. Otherwise, it just saves the move in the cache.

- Since I now have the Google App Engine SDK, I actually tested these changes.