At very end of your page you see
var histManager = new CriteriaHistoryCoordinator(criteria);
viewMng.addObserver(new ViewManagerHistoryManagerObserver(viewMng, histManager));
Pretty easy to get something working with YUI BHM (documentation). However I think Google’s manager – used by GWT is prettier. Yahoo’s support multiple modules, though.
If you have a GMail account you can see for yourself. Once you get into your inbox you’ll see the following on the URL:
Click on Drafts and you’ll notice it’s an ajax call. However the url changes to
Clicking on the back button will go back to /#inbox as expected. If you click Older you’ll notice the pagination parameter:
Searching will also add its parameters:
Clicking on a message from a search results adds the message id:
You can then click Back three times to go back to your inbox.
With Yahoo’s implementation you’d register a module (just a key), a initial state and a callback function. Your initial url would be unchanged:
Once the user perform some action that changes the state, and you want him to be able to back to the original state, you’d call the function register passing the module name and the new state (string). Imagine a call like register(“mymodule”, “newstate”) would result in the following url:
If you were to have more modules, it would generate:
As you can see it’s not as nice as in the end it’s just a querystring. In my case, search criterias are going to state, so it end up like:
Not as pretty as google’s, but works for now.
This is something that we – developers – don’t pay much attention. “Ajaxy” apps keep changing the content/state and once the user navigates somewhere else, she looses everything when going back to “that” page.
You might want to design in a way that the user never navigates off (awful), you might provide something that somewhat replaces the bookmarking ability of the browser, and you can keep inventing things to circumvent the very nature of web apps. It all comes down when you realize that the most used button on the web browser is the BACK button.
My attempt to deal with this was, like always, searching for a jquery plugin that handles history. I found two, but they are very limited. I was about to start to write my own when I bumped into YUI Browser History Manager. No idea on how well it will play with jQuery.. but seems very complete.
I cannot wait to get this book. I’m especially interested in chapter 16. On our latest project I admit I thought JS would be large but somewhat manageable. Not surprisingly it turned out to grown extensively in complexity as we accommodate more and more requests from the users. I deeply regret for not have used some js strategy for unit testing – albeit time wasn’t on my side. I’d say that regarding lines of code, the rate is two lines of js code for each “server side” c# line of code.
John doesn’t need to prove how much he knows about JS. Being the author of jQuery and posts like this one – that makes me feel like the most ignorant js coder on earth – no doubt his book will be successful.
It rocks. Such an active and dynamic community. The documentation could have more samples though. My advice is that you grab the source from their SVN. I learned more reading their test cases than by reading their docs.
Got some mixed feelings about it. I’m definitely comfortable with it, but not sure it’s the best JS lib out there.
Castle and Prototype
MonoRail is too coupled with Prototype. I realized that after converting my UI code to jQuery only. One can argue that jQuery can work peacefully with prototype, but I think it loses all its sugar.
We need to fix that.
JS is not for sissies
Some useful references.