An elaborate statistics tracking system for League of Legends. It used to be a centralised PostgreSQL based system but now it's a stand-alone SQLite application. It was written in C# and makes use of the LibOfLegends RTMP library. It is licensed under the terms of the GPLv3. Unfortunately I stopped working on it in 2013-08. Check out the website for a longer explanation.
Somebody already complained to me about the current "hash tag routing" system which is really completely running in / without providing any other entry point (like, say /summoner/NA/123123). My original idea was transferring as much of the "soft web logic" to the browser side of things as possible to keep as much of the system configurable through the central JavaScript components.
However, this also has its drawbacks, as users are not able to use the "back button" in their browser, for example. Accessing new content by hash tags can require refreshes, I think. It might still be possible to detect changes in the hash tag conveniently somehow. Maybe there is some Javascript magic for this that does not require the use of polling location.hash.
Actually, I just realised a semi-convenient hack to work around this in JavaScript. One could provide a JavaScript implementation of the back/forward buttons which simply keep track of the hash changes over time and let users go back and forth between those. This way the user does not have to reload manually after changing the hash tag in the address bar.
encratite
commented
12 years ago
Somebody already complained to me about the current "hash tag routing" system which is really completely running in / without providing any other entry point (like, say /summoner/NA/123123). My original idea was transferring as much of the "soft web logic" to the browser side of things as possible to keep as much of the system configurable through the central JavaScript components.
However, this also has its drawbacks, as users are not able to use the "back button" in their browser, for example. Accessing new content by hash tags can require refreshes, I think. It might still be possible to detect changes in the hash tag conveniently somehow. Maybe there is some Javascript magic for this that does not require the use of polling location.hash.
Actually, I just realised a semi-convenient hack to work around this in JavaScript. One could provide a JavaScript implementation of the back/forward buttons which simply keep track of the hash changes over time and let users go back and forth between those. This way the user does not have to reload manually after changing the hash tag in the address bar.