There are at least thirty-two different ways to initialize a client-side Director.js routing object. I think I’m happy that I ran into a bunch of issues toying around with the more advanced modes because it got me annoyed enough to consider how little of it I could use and get away with.
Anyway, I’ve wrapped up a tiny CoffeeScript class that encapsulates a contained instance of a Director.js client-side router and provides an extremely simple (and importantly predictable) callback on route change. Nothing fancy by design: the main application will take car of figuring out what the route means. There’s no recursion, assistance unboxing parameters, asynchronous route processing or any of that.
The Coffeescript class declaration is checked into the Encapsule Schema repo here:
This class is now integrated into Schema bootstrapper and is loaded essentially first affording an opportunity for the bootstrapper to parse the route, grab for example, debug flags or whatever, and then continue through boot. Once boot completes, the main application logic takes over the single route change callback exposed by Encapsule.app.InPageHashRouter class.
You can see this action in tonight’s Schema test build (I’ve left my debug console up in this build so you can see what’s going on):