Adnre - mine is actually roughly based on digitarld's lib (which is for moo 1.1). Ryan - i've looked at your example before, and i've thought about switching to it. the problem is that it uses a lot of calls to element storage for each of its actions, and this could become quite expensive for iterations that run few times a second. i was wondering if this could actually be done with using scope variables instead of element storage (thus saving a lot of lookups). the concept of providing a natural onhashchange behavior does seem much better than doing it by class... not sure if this is the right place for these discussions...
jay - mine's been tested working perfectly on Opera 10. not sure about previous versions On Thu, Jun 24, 2010 at 11:13 PM, André Fiedler < [email protected]> wrote: > 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 >> >> > -- Arieh Glazer אריה גלזר 052-5348-561 5561
