Navigation class -- seeking input!

[Jay]

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-navigation-class/

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!

[אריה גלזר‎]

this one is actually very similar (behavior wise - i haven't looked into the doe itself) to my 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)

--
Arieh Glazer
אריה גלזר
052-5348-561
5561

[Jay]

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, אריה גלזר <arieh.gla...@gmail.com> 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 <jay.d.carl...@gmail.com> 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...

[Ryan Florence]

Add this to the mix:

http://github.com/rpflorence/Mootools-window.onhashchange

[André Fiedler]

One more: http://digitarald.de/project/history-manager/

2010/6/24 Ryan Florence <rpflo...@gmail.com>

[אריה גלזר‎]

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

[nwhite]

On Thu, Jun 24, 2010 at 2:28 PM, אריה גלזר <arieh....@gmail.com> wrote:

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).

Why would this be expensive? Mootools uses an internal cache for elements so there is very little overhead. key/val memory store, it doesn't get much faster then that.