One more: http://digitarald.de/project/history-manager/
2010/6/24 Ryan Florence <[email protected]> > Add this to the mix: > > http://github.com/rpflorence/Mootools-window.onhashchange > > > On Jun 24, 2010, at 1:56 PM, Jay wrote: > > > That's an interesting way to do an event model. I'll dig a little > > deeper and see where our functionality overlaps and where it differs. > > Looks way more polished than my first-revision code. (for example, I > > had no idea of the Back/Forward functionality in Opera -- although the > > latest version seems to detect my hash changes correctly). > > > > On Jun 24, 8:31 am, אריה גלזר <[email protected]> wrote: > >> this one is actually very similar (behavior wise - i haven't looked into > the > >> doe itself) to my HistoryManager< > http://mootools.net/forge/p/historymanager>. > >> there are actualy quite a bunch of these types of handlers. a while back > i > >> tried to find a way to generalize the process by spliting my classes > into 2 > >> - one for the hash-change event and one for the specific state-observing > >> functionality. i wonder if we could find a way to merge these (no point > >> doing double maintenance for the same functionality) > >> > >> > >> > >> > >> > >> On Thu, Jun 24, 2010 at 11:11 AM, Jay <[email protected]> wrote: > >>> I created a little utility class that combines window.location.hash > >>> monitoring (and uses the onhashchange event when available) with query > >>> string <---> object conversion functions, providing a handy interface > >>> for creating and retrieving application states. > >> > >>> As soon as you instantiate the class, you can attach a > >>> "navigationChanged" event to it, and whenever the hash changes, it > >>> will be converted to an object and sent out with the event. The class > >>> also provides utility functions for modifying the hash with key/value > >>> pairs. Combining these two pieces of functionality allows the class to > >>> sit between your UI elements and the actual application logic. > >> > >>> Because the class relates unrelated functionality, it's not really > >>> written in the MooTools style -- for example, I don't extend the > >>> hashchange event, since the event's data isn't the hash string, but > >>> rather an object decoded from it, so I have to do everything in the > >>> class. > >> > >>> This is the first class I've ever "released" -- I would love someone > >>> smart chiming in with suggestions on ways to improve it. > >> > >>> You can find information about it here: > >> > >>> http://www.jaycarlson.net/blog/2010/06/22/a-mootools-powered-ajax-nav. > .. > >> > >>> Or just download the class at > >>> http://www.smmirror.com/js/debug/classes/navigation.js > >> > >>> (docs are in the comments section at the top of the file). > >> > >>> I'm eager to hear what you guys think! > >> > >> -- > >> Arieh Glazer > >> אריה גלזר > >> 052-5348-561 > >> 5561 > >
