A quick update on Really Simple History

Brian Dillard, Tuesday, April 15, 2008 @ 2:19 pm

Progress on Really Simple History is progressing nicely, though I'm taking a break this week to finish up my presentation for next week's O'Reilly Web 2.0 Expo in San Francisco (more on that tomorrow).

In taking RSH one step closer to a 1.0 release, I am basically re-writing everything from the ground up. My objectives include the following:

• Fix all outstanding bugs: This is a no-brainer.
• Support more browsers: For IE8, I'll be using its built-in hash-change event to get rid of timers. For Firefox 3, I'll basically just road-test to make sure everything still works. For Safari 3 and Opera 9.5, I'll do better version detection so that hacks required by earlier releases of those browsers get deployed only for the versions that need them. Safari 2 and Opera <9.5 will still be hack city, but the latest and greatest will use the same methods as Firefox.
• Untangle the code: In Brad Neuberg's original RSH 0.4, he had to support only two different methods of history management: The IE6 version, and the verison for Opera/Firefox. (Safari wasn't supported). Thanks to huge bugs in Safari 2.x and Opera 9.x (prior to 9.5), RSH 0.6 needed branching code within several different methods to handle four different versions of its history storage routine. With support for IE8, that will jump to five separate implementations. Clearly, the library would be much easier to develop, debug, maintain and read if code to support each implementation weren't intermixed within several methods. At the cost of a KB or so in code size, I plan to use lazy function definition so that browser-specific code can be encapsulated better within each method.

• Use one global object rather than two: dhtmlHistory and dhtmlStorage will go the way of the dinosaurs to make way for one unified object called rsh.
• Lock down the code: I'm using Douglas Crockford's JavaScript Module Pattern and closures to make private methods truly private. The new rsh object will expose only those methods that application developers actually need to use.
• Simplify, simplify, simplify: The plain-vanilla version of the new rsh object will support the use case that, according to my users, is most popular: The use of the URL hash as a virtual querystring. RSH 0.4 and 0.6 also offered an alternate use case in which the URL hash could serve as the key to recover a large JSON data store squirreled away on the page in a hidden form field. However, this use case seems to be used by a minority of application developers, and it adds great complexity and size to the library. I will still provide this functionality, but it will be isolated in its own plug-in.
• Adapt or die: Speaking of plug-ins, all low-level DOM functionality (cross-browser event listeners, JSON utilities, etc.) will likewise be isolated in a separate adapter file. I'll then call upon members of the RSH community for help fashioning adapters for various popular Ajax frameworks. The result will be a modular library that can be deployed with its own adapter in the absence of an Ajax framework, but whose size can be reduced when low-level functionality can be delegated to other frameworks at use in the application.

I look forward to sharing the code-in-progress in the coming weeks.

agile ajax

Comments: 7 so far

• Leave a comment
• Comment feed for this post
• TrackBack URL

1. 

   Sounds like you are making some great choices about refactoring RSH and moving it forward.

   Wanna grab a free lunch at Google next week when you are in town? Ping me by email and we can schedule a time to meet.

   Comment by Brad Neuberg, Tuesday, April 15, 2008 @ 8:08 pm

2. 

   thanks, that was good to know

   Comment by bloggers mosaic, Wednesday, April 16, 2008 @ 9:06 am

3. 

   This is good information, thanks for the update! A number of users on the RSH group have posted about IE6/7 losing the cached history object when navigating offsite then clicking the back button. I’ve really wanted to use RSH, but this bug has kept me from doing so as I’m in an intranet scenario where (roll eyes) IE is the standard browser. I really hope this is an item that you’re working on as, regardless, IE (specifically legacy versions of it) tends to rule the airwaves so to speak.

   Comment by Kerr, Thursday, April 17, 2008 @ 7:50 am

4. 

   Great news. I dont know wether it has been suggested but it would be great if you added some way of changing existing history entries after they have been added. I guess the ability to change the most recent history entry would be the most desireable.

   Comment by Robert Kajic, Tuesday, April 29, 2008 @ 3:05 am

5. 

   Agree completely with the “bloggers mosaic” comment about the problems with IE6 and IE7. Unless it supports Internet Exploder I can’t use it in a commercial environment.

   If anyone knows of a COMPLETELY FUNCTIONAL history manager please email me at tewehrej@moc.oohay (reverse the name and ISP in the email address — possibly vain attempt to stop spam-bots on my part).

   Jerry H.

   Comment by Jerry Hewett, Tuesday, April 29, 2008 @ 4:11 pm

6. 

   This is great news. Any idea of a release date?

   Comment by Jamie Hill, Thursday, July 24, 2008 @ 2:34 pm

7. 

   Sorry for the double comment but do you know a way to determine which of the ‘back’ or ‘forward’ buttons were clicked in the listener.

   Thanks,

   Jamie

   Comment by James Hill, Monday, July 28, 2008 @ 12:16 pm

Leave a comment