Archives

I committed several weeks ago to roll Really Simple History 0.6 RC1 over into a final release on Dec. 1. That’s still the plan, but I’m having trouble resisting the urge to tinker. I’m starting to see how a project like this could remain in indefinite limbo if I don’t just draw a line in the sand and release a final "hard" version that people can rely on for production code. The current SVN trunk includes a number of backwards-compatible enhancements. I’m working hard to test them all as comprehensively as possible, but I’m going to avoid adding risk to 0.6. Instead, I’ll save them for 0.7, which will come out in beta before Christmas.

The enhancements targeted for 0.7, some of them already complete, include the following:

• Configurable location for the blank.html file: You’ll be able to override the name and directory location of blank.html in case your server architecture demands that it be served from a different location.
• Automatic handling of history points whose keys contain spaces or other special characters; encodeURIComponent is my friend.
• Automatic title changes: You’ll be able to pass a third argument to dhtmlHistory.add and update the document title with its value. You’ll also be able to pass in a base document title through the options bundle so that each call to add just swaps out the subtitle.
• One-line initialization: You’ll be able to pass your listener into the dhtmlHistory.initialize without having to call addListener separately.
• Private methods that are actually private: Methods that are currently marked "private" but are accessible to anyone will become inner functions with no public access.
• Better global namespacing: I was hesitant to change the API for the 0.6 version, but I’d like to follow the YUI model and group all of RSH’s objects into a single global variable. Instead of dhtmlHistory and historyStorage, we’ll end up with RSH.history and RSH.storage.

The roadmap for 1.0 includes the following:

• JSUnit and Selenium test suites.
• Adapters for major frameworks using the MooTools model.
• Customizable downloads.
• Serious tutorials and documentation.

In the meantime, downloads for 0.6 RC1 have crept to just under 350 almost 700. Look for me to "flip the switch" on Saturday, promote 0.6 to the stable production version, and deprecate 0.4 once and for all.

Technorati Tags

• ajax
• javascript
• bookmarking
• Really Simple History

Now that I’m getting immersed in the conference circuit, I’ve got a new game to play every time I attend a session on any technology meant to ease the pain of client-side development. Based on the session abstract, I lay odds as to how long it’ll take me to hear the presenter say something like this:

Without [insert name of tool here], you’ll have to write your own JavaScript. I don’t know about you, but I sure don’t wanna do that!

I wasn’t surprised when I experienced this several times at Adobe MAX a few months ago, but it sure bummed me out to hear David Geary say it this weekend at No Fluff Just Stuff. I guess I shouldn’t be surprised that this message would play well to the Java-centric crowd at NFJS. In fact, I should probably give Geary props for getting almost 75 minutes into his three-hour talk on Google Web Toolkit before delivering the blow.

My colleague Dietrich Kappe has obviously been a leading proponent of GWT, but until Geary’s talk I hadn’t really gotten past the high-level view. I have to say, despite the fact that GWT is designed to obviate the need for traditional client-side development, Geary’s talk got me excited enough to give it a shot. At most every job I’ve ever had, I’ve wanted the chance to expand my skill set by stepping into a junior Java role on at least one project. It’s never happened, though; once you’re good at one thing, it’s pretty hard to convince your boss to let you flail around trying to learn another on company time. Perhaps a GWT project or two will finally give me some real Java exposure in the client-side environment I know so well. It’s pretty ironic, though, to write code in a language you don’t understand just to have it compile "down" to a language you do.

JavaScript authors, have any of you given GWT a shot? I’d be interested to know what you learned, so leave me some comments.

Technorati Tags

• GWT
• Java
• Google Web Toolkit
• JavaScript

There’s never been a better time to be a JavaScript developer. JS hit the big time with the advent of Ajax, and overnight client-side programmers went from being the redheaded step-children of the web-development world to front-and-center participants in the RIA revolution. Even if you’re working on a team of one, there’s a thriving global community of JavaScript gurus constanly pushing the language forward, working out browser kinks, demonstrating how to import concepts from other languages and computing paradigms, and otherwise inspire you. It’s a big change from 10 years ago, when you had Webmonkey and the David Flanagan book and a few cookbook-style compendiums of tips and tricks. This is seriously the golden age.

Working for the last couple of months on Really Simple History, though, I’ve become interested in the way specific techniques become the flavor of the month and quickly redefine how we conceptualize "good" JavaScript coding practices. Take, for instance, DOMContentLoaded. After the first version came onto the scene, within a matter of months we had many competing implementations of the basic concept that your scripts shouldn’t have to wait for window.onload to fire before getting down to business. Now, DOMContentLoaded is the de facto start point for many, many JavaScript applications. Heck, it’s even the basis of the entire jQuery event model. There’s nothing wrong with that, but widespread use of Ajax toolkits can conceal the fact that DOMContentLoaded is just a collection of hacks. It works, as long as our toolkits keep iterating one step ahead of the browser vendors. But do we really need it?

At Orbitz Worldwide, my previous employer, we implemented a first-rate unobtrusive-JavaScript architecture. (See it in action at Ebookers UK.) Everything was progressively enhanced from dumb markup. That meant our application worked just about everywhere. But it also meant lots of DOM parsing and initialization that couldn’t begin until window.onload. As our application grew, this caused enough of a UI flicker – form controls turning into widgets, links morphing into Ajax calls – that we needed to jump the gun on window.onload if we wanted a good experience for the majority of users … the ones with modern, JS-capable browsers. DOMContentLoaded made sense, and architect Nik Krimm pounced on it.

But for a large subset of websites, there really isn’t THAT much difference between window.onload and DOMContentLoaded. If you’re merely adding an unobtrusive behavior layer to a traditional, content-driven website, chances are that good old window.onload will perform just fine. There’s usually little reason NOT to use DOMContentLoaded. But unless you are developing a desktop-style webapp or implementing progressive enhancement on a foundational level, it’s not really necessary. And in certain cases, it just flat-out won’t work.

An enthusiastic beta-tester discovered such a case when trying to initialize RSH’s dhtmlHistory object from DOMContentLoaded. It broke, and I immediately knew why: RSH relies on the ability of modern browsers to auto-save form data for the life of a session. RSH uses a hidden textarea to cache serialized Ajax application state and render the back button useful again. Internet Explorer doesn’t repopulate the cached value of that textarea until an instant after window.onload. If you try to access that cache during DOMContentLoaded, it simply isn’t there. This is true of both IE6 and IE7. Therefore, you need to wait for window.onload.

I’m not really sure there’s any big conclusion to draw from this example. As I said, it’s just interesting to me that in the space of a year or two, DOMContentLoaded has become a de facto standard. As we pile browser hacks on top of one another to push the web forward, sometimes they’re going to conflict. Luckily, we can always peek past the curtains and figure out what’s  going on behind the scenes.

• Ajax
• JavaScript

After much tinkering, I am happy to announce the release of Really Simple History 0.6 Release Candidate 1. This version offers a number of improvements and bug-fixes over the 0.6 beta released on Oct. 23. I encourage the 600+ people who have downloaded the beta to upgrade immediately to this release candidate. As for the 3,200+ people who have downloaded the stable 0.4 version in the last two months, it’s your turn, too. Beta-testers helped me put RSH 0.6 through its paces in a wide range of browsers and platforms, alongside a wide range of Ajax frameworks, and the result is solid. I fully expect this version of the code to become the new, stable 0.6 release on December 1, barring any show-stopping bug reports.

What will change between now and the final release

We’ll provide a minified version of the stable release for download. We’ll also provide links to sample apps. That’s it.

How to upgrade

• Visit the downloads tab at our Google Code repository.
• Join our Google Group for ongoing updates.

Change log

• Rock-solid support of Opera up to 9.5 beta for Mac and PC.
• Rock-solid support of Safari/Mac from 2.03 through 3.03.
• Tons of internal refactoring.
• Two-line initialization of dhtmlHistory and historyStorage (as opposed to the previous two init calls in the library and two more in your code).
• Support for an optional options bundle in the initialization call to trigger debug mode or override default JSON methods.
• Compatibility with Prototype thanks to the aforementioned JSON override capability.
• Additional choice in JSON parsers; we now ship with a default 2007 JSON parser that alters core object prototypes and an older 2005 version that doesn’t.
• Better user-agent sniffing that’s more resistant to UA spoofing.
• Removal of a bug introduced in 0.6 beta that threw an error when you hit a virgin (hashless) page state.
• Graceful swallowing of errors in non-debug mode.
• Replacement of equality operators with JSLint-friendly identity operators where appropriate.
• Cleanup of a little cruft from the 0.4 and 0.6 beta versions.

Browser compatibility

Supported

• IE6 (Windows)
• IE7 (Windows)
• Firefox 2.x (Mac, Windows, Linux)
• Opera 9.22-9.5 (Mac and Windows)
• Safari 2.03, 2.04 and 3.03 (Mac)

Unsupported

• Safari 3.x (Windows): Falls prey to fundamental bugs in Apple’s current beta release.
• Non-Mozilla-based Linux browsers.
• Any browser not listed above; test before you deploy.

Want to showcase your RSH-enabled application?

If you use Really Simple History 0.6 in your production code, I’d love to take a look and possibly highlight your app in a future post. Please email me, comment here, or send a note to our Google Group.

Technorati Tags

• JavaScript
• Ajax
• Really Simple History

It’s been a bit over a month and a half since ZK 3.0 RC was released and the ZK team has sure been busy. The list of new features is long, but has a surprisingly large number of them are new from RC1 to final:

• The performance of ZK is much improved – four ~ five times faster.
• Server push (really polling) is enabled which allows you to update client’s information actively and the usage is simple and intuitive.
• The ZK Layout component which simplifies the job of UI designer.
• Customize layout of ZK components using CSS definitions.
• Add forward and apply properties to realize MVC approach more easily.
• SimpleListModelSharer – integrates server push and ListModel allows you to update data of clients based on the same data automatically.
• New expression of annotation is ease of use, and easy-to-read.
• TreeModel is introduced which simplifies the job of Tree rendering.
• Flash components allow you to play audio and video files. (including youtube clip)
• Native namespace is implemented to speed up the performance while integration with HTML.
• To speed up the performance of ZK, EL evaluator is pluggable, and a new way to render ZK components is introduced.
• More integration with other frameworks, ZK has integrated with JSF, JSP, and Ext-JS.

I find the addition of the layout component interesting. It seems that everyone from GWT, Tibco GI, Ext JS, etc., is moving toward the programmatic model of layout, i.e. DockPanel and so on. In fact, several of the Web 1.0 frameworks have been doing this for a while now, and of course the desktop GUI frameworks have been doing that since the stone age, so the wheel does seem to get reinvented again and again.

I do think that CSS, while giving you fine-grained control, can be a bit unwieldy for day-to-day use. Being able to stuff widgets into containers and have them handle layout is very tempting and convenient. But note the presence of fine-grained layout managers (GridBag anyone?). In my many years of developing applications, I’ve seen projects sink under the weight of getting everything within a pixel of perfect. Under those circumstances, fighting with CSS through the damp blanket of a layout manager is torture indeed.

P.S. ZK Mobile 0.8.7 was also released and is now compatible with ZK 3.0.

Technorati Tags: ajax, zk

Lots more news on Really Simple History, the open-source Ajax bookmarking library I’m now spearheading:

• SVN – RHS now has a Subversion repository. The version trail starts with the 0.6 beta. Since its release, I’ve been committing bug fixes and refinements as I get them tested. Feel free to check out a read-only copy if you’re already bored with the beta.
• Mailing list: I’ve also started a Google Group for the project. In the future, that will become the primary means of communication for RHS, and I’ll get back to other subjects here on Agile Ajax.
• Bug fix: for/in loops – It’s universally acknowledged that they’re considered harmful, but I unthinkingly added one to the codebase just before zipping up and publishing the 0.6 release. That’s now remedied in SVN.
• Bug fix: Safari – The initial 0.6 beta also had a major shortcoming in its Safari 2/Mac implementation. Bookmarking worked great as long as you didn’t navigate away from your RSH-enabled app and then come back. If you did, goodbye, history. It turns out that the history.length hack fails in these circumstances because the browser resets the value each time the page loads. My solution was to add yet another hidden form field and store the initial history.length value there the first time the app loads during a session. Upon subsequent loads, I grab the value from this field instead of from history.length. Hacks upon hacks upon hacks, but it works.
• Enhancement: test page – I’ve continued to refine the test page. It’s now got a single logging console instead of three separate ones, plus easier-to-read log messages and more user-friendly controls.
• Download archive – I’ve created a bunch of for-posterity-only downloads of Brad Neuberg’s original versions 0.1 through 0.4. It seemed a little silly to create a retroactive SVN trail for them.

As of this writing, 225+ people have downloaded 0.6 beta. That’s in addition to the 2150+ people who have downloaded the stable 0.4 release in just the six weeks that it’s been hosted at Google Code. It’s really hitting me how many people actually use this thing, which spurred me to spend my weekend on the tasks listed above. I’m working hard to address the following additional issues before putting out a non-beta release:

• Bug fix: Safari infinite loading bug – I want to get rid of the stupid, eternally spinning disc on my RSH Safari tab. The fix is out there in the world; I just need to implement it.
• Bug fix: Opera history dies when you navigate away and back – I licked this in Safari, so now on to Opera.
• Bug fix: IE user-typed history entries – RSH 0.4 handled these properly, but I broke something in 0.6. It’s a corner case, but I’d hate to undo Brad’s hard work to handle it.
• Enhancement: window.onunload – RSH has always clobbered previously defined onunload handlers. In this era of memory leaks and the onunload events that help plug them, I want to handle this more gracefully.
• Enhancement: JSON bridging – The standard JSON library I’m shipping with RSH doesn’t play well with Prototype. I need to provide a better mechanism than brute force for individual users to override these methods with their own JSON serializer and stringifier.
• Enhancement: Graceful failure – I want to add better user-agent detection and set a global flag to just turn RSH off for those user-agents that aren’t supported. Right now, for instance, the library thinks Safari works, period, when really only Safari 2/Mac works perfectly.

I’m pretty confident I can get most of this committed this week. If you’re an RSH user, please let me know if there’s anything I’m overlooking.

Technorati Tags

• ajax
• javascript
• bookmarking
• Really Simple History

So I ended up doing some last-minute fiddling with the Really Simple History 0.6 beta before posting it for testing over at Google Code. Matt Snider pointed me to a potential SSL problem with using DOM methods rather than document.write to insert IE’s hidden iframe. I’ve got four places where I need to insert stuff into the DOM, and I had already hemmed and hawed quite a bit about whether I should use DOM methods, document.write or a mixture. For now, based on Matt’s comments and the verbosity of DOM methods, I’ve reverted back to using dirty-but-concise document.write. I’m going to continue testing this in as many browsers as possible before settling on a permanent solution.

While fiddling, I discovered something interesting that contradicted yesterday’s (now-corrected) post. I originally wrote that if you’ve got script-generated DOM elements that need to be treated as native to the document (so, for instance, you can persist form values across an entire session regardless of whether you navigate off-site), you must use document.write to insert them into the DOM. Not true, as it turns out. It doesn’t matter whether you call document.write or standard DOM methods from the head of your document. Either way, both methods seem to result in "native" HTML form fields that can properly persist values. Looking at Firebug or Opera’s developer console, you can see that these elements end up being children of the body element even though they were, in fact, inserted into the head element. Modern browsers are so smart!

This whole issue of when to generate DOM nodes brings up an interesting facet of library development: Deciding how much stuff the end user (i.e the developer who is leveraging your library) has to do in the actual document. For most libraries, it’s not an issue, because their objects and methods aren’t going to do anything until called by application code. But it’s different for something like Really Simple History, which relies on a variety of browser-specific hacks, many of which need to be set up before the DOM finishes loading. Sure, you could include inline script blocks in the body of your document to write the hidden, browser-specific DOM elements that enable your library to function. But developers really hate it when the use of a library forces them to fiddle with their page templates. Library authors have to get creative – for instance, by calling their initialization methods in the library file itself, even though that will result in DOM elements getting written to the document head.

As I said in yesterday’s post, Ajax history management works only thanks to a variety of browser quirks and hacks. If you want clean code that doesn’t break any standards, then you should cross history management off your list of requirements.

Things get even more interesting when your browser-specific DOM hacks work best when they’re included as actual markup. My beta is out there, but I’m still scrambling to figure out the best strategy for Opera which, thanks to a bug introduced in 9.x, relies on a hack involving an image tag a crazy URL:

<img src="javascript:location.href=’javascript:dhtmlHistory.checkLocation();’;" style="visibility:hidden" />

This image throws errors in IE, so I couldn’t tell developers to include it in their actual markup even if I wanted to release a library with such brittle implementation rules. If I want it to go in the actual HTML, I’d have to ask developers to do server-side browser sniffing and include it only for Opera users. YUCK. Yet all of the methods of writing it to the DOM via script have drawbacks. The way I’m doing it now, it works in Opera, but it throws an exception in the JavaScript console. Sure, only developers will see that exception, but still…. I guess I still have my work cut out for me.

Technorati Tags

• ajax
• javascript
• bookmarking
• Really Simple History

Late tonight over at Google Code, I’ll be posting a beta of Really Simple History 0.6 for testing. The goal is to elicit help from RSH users in chasing down any bugs I’ve failed to catch, then push out a stable release around Halloween.

I’ve tried to be as ambitious as possible with this release: full support of IE7/Win, Safari/Win, Safari/Mac, Opera/Win, Opera/Mac. I’ve didn’t quite get there, but I got close.

Features in the new version include:

• Full support for IE7/Windows (though my only Windows machines use IE7 Standalone, so I need help testing on "real" IE7 installs).
• Full support for Safari 2/Mac (though I’m still trying to eliminate the "infinite loading" bug before I push out the beta).
• Partial support for Safari 3/Windows (hampered by bugs in the current beta version of the browser).
• Full support for cross-platform Opera 9.22 (though you may need to hard-code an image into your markup).
• A totally revamped test page that allows you to play with the library in your browser of choice and see how it works behind the scenes.

As always, RSH works beautifully in Firefox 2 for Windows and the Mac. I hope to give it a good shakedown on Linux browsers in the next release.

So what is Really Simple History, and why am I updating it?

An Ajax bookmarking and history-management framework originally developed by Brad Neuberg, RSH became my responsibility a little over a month ago. I tinkered with it for a few weeks, then finally camped out with it for most of the past week to get a release out.

This is the first time I’ve ever contributed in this manner to an open-source project. It’s been a lot of fun, but it’s also been maddening, as anybody who’s ever dug into the bowels of cross-browser history management can tell you. Here’s a sampling of what I’ve learned from RSH:

Safari is crazy

Plenty of people who’ve worked on Ajax bookmarking projects have commented about this, but it only becomes clear once you’ve actually seen it in action. Getting this thing to work in Safari 2 for the Mac took a wildly disproportionate amount of time considering its market share. I wouldn’t have been able to do it without Bertrand Le Roy over at Microsoft, whose blog entry on the development of the .Net history manager pointed the way for both Safari and Opera.

As Le Roy and others have noted, the Safari 3 Windows beta is so buggy that history management is hopeless. You can enable the back button for Ajax apps, but once you use it, the forward button becomes disabled. I noticed yet another wrinkle in this behavior (skip ahead if you’re easily bored):

Navigate to a non-RSH site – Google, for instance. Then travel to an RSH site, create some history entries via RSH, and use your back button. The forward button stops working: a known bug. Now keep hitting back until you get back to Google again. Suddenly, your forward button works again. Hit forward and land back in your RSH app. Magically, the forward button continues to work.

If I hadn’t spent so much of the last week lost in Safari-land, this interesting behavior might be worth further investigation. For now, I’m just hoping the Safari 3 team fixes this before the final Windows release.

Don’t try to retire document.write just yet

A couple of different RSH users suggested getting rid of Brad’s original calls to document.write in favor of standard DOM methods for adding elements to your page. That approach worked for some elements, but not for others.

In IE, RSH writes a hidden iframe into the document and uses the location and history of that iframe to help it track application state. Writing the iframe with document.createElement works just great.

But for all browsers, RSH uses a hidden textarea to store the entire history stack behind the scenes. This powers one of RSH’s coolest features: its ability to retain history even if you navigate away to another site and then come back to your RSH application. This works because modern browsers retain form-field values throughout an entire browser session. But they do so only for form fields that exist in the DOM natively – that is, exist in the actual HTML markup or get inserted via document.write get inserted into the DOM before it’s finished loading. 

If you create a form element after your DOM is already loaded, the browser has no way to persist values in that element after you leave the page. Each time the page loads, even from the cache, you essentially create a virgin new form field. I’m therefore using document.write for the hidden textarea – and for the hidden form field I’ve added to RSH for Safari support.

UPDATE: As it turns out, it’s immaterial whether you use DOM methods or document.write. The important thing is to use either method before onload fires. I ended up using document.write in the 0.6 beta because of SSH concerns and the fact that it’s so much more concise. For more on this topic, see this subsequent post. 

Because of the way RSH is structured, these elements actually get written to the head rather than the body of your document. Still, it works, and it should only offend the most anal-retentive of standards geeks. After all, if you’re hacking the browser 10 different ways from Sunday just to enable Ajax bookmarking, then inserting a bit of non-validating markup via JavaScript is hardly the worst of your sins.

RSH won’t be hitching its wagon to [insert name of your favorite framework here]

A few users suggested rewriting RSH in Prototype so it would be more compact. I appreciate the impulse, but I think that defeats one of RSH’s chief virtues: the fact that it’s written in Plain Old JavaScript and doesn’t lock you into any specific Ajax framework. It plays well with any library you want it to: Prototype, jQuery, YUI, whatever. (If it doesn’t, please file a bug so I can find out why.)

A little JSON never hurt anyone

The one library that RSH does require is a JSON parser; it ships with the latest open-source version. RSH 0.4 included an earlier version of the parser in the same file as its native code; I’ve broken it into a separate file under the logic that many users will already be serving a similar library. RSH’s methods don’t actually call toJSONString or parseJSON directly; instead, I’ve provided bridges so that you can hack in your own JSON methods without having to modify the guts of RSH itself.

Future roadmap

I’ve got quite a punch list for the next release:

• Provide minified versions of RSH and JSON for download
• Make use of Crockford’s module pattern for better encapsulation
• Add official support for Linux browsers, Safari 3/Mac and Safari 3/Win

That’s the future. For now, I have to get 0.6 packaged up and ready for testing. Check Google Code late this evening or first thing tomorrow.

Technorati Tags

• ajax
• javascript
• bookmarking
• Really Simple History

Echo3 is showing a few more signs of life. Since my update last month on some early details of Echo3, the pace has picked up. No alpha release, but already there are two forums, one especially for folks looking to contribute to Echo3 development. Also, a few other things worth mentioning about Echo3:

• The SVN repository can be found at svn://svn.nextapp.com/echo3/trunk (Echo3Extras are at svn://svn.nextapp.com/echo3extras/trunk).
• If you just want the binaries (or binaries with source), the Echo3Go project is handy.
• Initial performance numbers of Echo2 vs Echo3 show a more than 2x improvement in performance.

Further, a more detailed description of the new features, design principles and ideas behind Echo3 can be found on the wiki. Two items that are especially interesting for those looking to write their own components:

• Automatic Serialization: Data objects sent between client and server can be automatically serialized between Java, XML, and JavaScript. The serialization architecture is extensible–serialization code for new object types may be added by the developer.
• Simplified Client/Server Synchronization Peers: Serializing components and commands between client and server is performed automatically using the built-in serialization architecture. The component developer only need specify which properties should be sent (for components, all local style properties are automatically sent).

Serializing and deserializing data between client and server can be one of the more timeconsuming and error prone parts of developing Ajax apps. Packaging this into the framework with improve productivity at the very least.

Technorati Tags: ajax, echo3, echo2

Supplementing GWT’s basic set of widgets with wrappers around those of existing widget frameworks has become a bit of a cottage industry. There are wrappers for Scriptaculous, JsGraphics, TinyMCE (see the GWT Widget Library for these), Ext Js and many more. Now add Rialto to that list. (For a demo of the Rialto widgets, such as the interesting GridTreeView, see here.)

One shortcoming of Rialto’s GWT wrapper, however, is that all of the widgets are subclasses of JavaScriptObject rather than Widget. A best practice that has emerged for wrapping other frameworks is to wrap a Widget adapter around a JavaScriptObject so that the wrapped framework’s widgets can play nice and integrate with other existing GWT widgets. The Rialto wrapper doesn’t do that and also implements a parallel set of event, clicklistener and other classes. This shortcoming needs to be resolved in order for this particular framework wrapping to be useful.

Technorati Tags: gwt, rialto, ajax