With all of this talk of fancy libraries and so forth, and with the whole Domino web world abuzz with tales of Ajaxian glory, it's sometimes hard to remember that Domino already provides us with a lot of sophisticated functionality. You say you need a field to refresh? There's a checkbox on the Field Properties box to handle that for you. Sure, it takes a post-back to do it, but most web application platforms have done much the same thing since the dawn of time (about eight years or so ago). All Ajax brings to the party is immediacy and fluidity, really. You can make an Ajax app last all day on a single page — something like Writely is meant for that sort of user experience — but the average Domino-suited application (or application suite) is more generally suited to defined "locations". That is, each task type would have its own workspace. Changing pages is not a dread thing to be avoided at all costs.
Okay, what does all of this blathering mean? It means that Domino views, forms and pages created in Designer already do pretty much what our users expect them to do. They just might not do them in the most elegant of ways. For instance, it may take a user several seconds (during which, of course, she has been typing madly away to record one of those elusive thoughts that will never be formulated quite the same way again) to realise that the form has already been submitted for refresh and all of her recent work has gone for naught. That is something that the immediacy and fluidity of Ajax can alleviate.
Now, as proud as I am of the bits of the library I've already put together, I am aware that as it stands, it still requires that a developer's efforts be concentrated on cooking a web application. atDbLookup() is way freakin' kewl (and will be so much kewler when I've gotten the automatic request and callback marshalling bulletproofed), but somebody still has to add it to a form, field, or button event in order to make it work. I really can't wait to see what other people can do with the tool once it has matured beyond the pre-alpha stage. I'm sure there are a couple or three web wonks out there who will build things of exquisite beauty when they don't have to concentrate so much on the mechanics of the app. They will, though, be aware that they are building a web application at every step along the way. Even something like prettyView() takes developer input, if only to add the code to the database and the passthru tag to the $$ViewTemplate. It doesn't have to be that way.
This is where Jack Ratcliffe and I meet face-to-face, so to speak. The Domino Web Tools project was meant to automate a lot of those processes, and I'm pretty sure that having direct Formula analogues handy will make that go a lot more smoothly. As I get deeper into the library project, it's easy to see how something like DWT can become overwhelming and go fallow for a while. Its a Project with a capital P. It was great to see Jack responding to the original library posting.
That's where the more ambitious part of Domino Web Tools comes in. In the early hours of the project formation, at least, there was much talk of automating as much of the webbification stuff as possible. You know, reading a form's design, say, and auto-generating the replacement parts. Adding datepicker widgets with the appropriate regionalisation to date fields, that sort of thing. It's all of that event code, though, that's the real sonofabee, at least when you have to create equivalent client-side web code. That is, I hope, where this library would make the greatest difference.
Ultimately, that's what I'd like to see happening. As much as I'm jazzed about super-innovative web development on Domino, I think that it may be far more important to the platform to make the low-hanging fruit hang a whole bunch lower.
That gets a little dicey when you want to abstract things away from the developer. In normal Ajax development, one would be hands-on enough to know where you are making requests and what sort of response handler you should attach to the request. That is precisely the sort of thing I want to take off of the developer's plate. In the example above, if the lookup isn't in the cache, then atDbLookup() should immediately return something to the refreshSelectOptions() function so it can terminate and let the user get on with life. In the meantime, the lookup can take as long as it takes (that depends on the connection speed and server load), and when it's done, it should be able to complete what refreshSelectOptions() started. Making that work cross-browser and one hundred percent reliably while preserving the entire calling context is one of those easier-said-than-done things. (Return to main text)