Tuesday, August 29, 2006

Building the Behaviour Layer

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.

Right now, when you have "Use JavaScript to generate pages" turned on and select one of the refresh options on a field, Domino generates an event handler like this in the onchange: _doClick("$Refresh",this,null). Overriding a handler like that is very easy to do in JavaScript: document.forms[name].FieldName.onchange = someNewFunction. As long as it's called after the form is loaded, it's nearly foolproof. That means that right now, today, almost anyone reading this has all of the tools they need to create a "behaviour layer" that runs through Domino web page and hangs the stuff they want to hang off of field events, etc. It isn't at all difficult, but it is extra effort, and it is oh, so easy for the behaviour layer (the custom event script for a page) to get out of sync with the form or page design.

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.

There are boatloads of Notes-client-only developers out there, many of whom never, ever stray beyond "pure Notes" applications (if they have to talk to another system, they'll use something like Notrix to do the talking), and who never step foot outside of the comfortable world of Formula Language. Many are only part-time developers — thay have "real" jobs filling up most of their time, and learning the intricacies of HTML, CSS and JavaScript is not something they'll give up their precious family time to do. Now imagine what it would be like for them to be able to create a truly usable, responsive, and (perhaps) even good-looking Domino web application by merely copying a couple of Design Notes into their database (or running an agent against the db to do it for them). Imagine the appearance transformed to look more like the thing they created in Designer. Imagine "Allow values not in list" still allowing a drop-down selection. Date fields with the date selector enabled still having them on the web. View dialogs and name-and-address pickers acting just the way you'd always imagined they should. Post-back behaviours replaced by in-browser updates. Computed fields computing right there in front of the user the way God intended. The one critical customer-interactive application a small Notes shop has does not have to be an aesthetic or functional embarrassment.

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.

It's one thing to add calls to a function like atDbLookup to a form. It's a relatively simple thing to make a server request to update something on the web page. But if you use the example I've given before, where the onchange of a field contains something like refreshSelectOptions("FieldName",atDbLookup("cache","","LookupView",this,2)), there is an implied contract of synchronicity. The refreshSelectOptions() function can't do what it needs to do until the atDbLookup() function has returned its values. Well, hell — we've just managed to lock up the user's browser the same way we would have by posting the form for refresh. Maybe not for nearly as long (and thanks to the way I do the caching, not every time, either), but there is that moment where the browser can't do much but wait for a reply. The big "A" at the start of the word "Ajax" stands for "Asynchronous". The object of the game is to notify the user that something is happening, but stay out of their way otherwise. That means divorcing the main activity from the event that caused it, and giving the request all of the info it needs to look after its own affairs when it's complete.

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)


Charles Robinson said...

Thanks for all your efforts and your explanations, Stan. There's another type of Notes-client-only developer that you don't mention. The ones who have done non-Domino web development and who use many of the features of Lotus including LotusScript, but don't use Java or JavaScript.

I fall into that category. I've done web development, and even attempted it in Domino, and trying to figure out all the myriad places finally made me throw up my hands in frustration.

When I can pick up something like Ruby on Rails and develop a functional (if not elegant) website in less than a day, but the same thing in Domino has me beating my head against a wall a week later, there's a problem. I won't disagree that part of it is me, but I will say that I have never found any good tutorials on how to go from the basic "Hello World" website to something like CSS Zen Garden.

I appreciate your efforts, and those of the people you link to (whom I never would have known about otherwise), and hope to one day be able to claim to understand how all the pieces of a Domino web site fit together. Keep the knowledge coming, I'll try to cram it into my pea brain somewhere. :)

term paper said...

Blogs are so interactive where we get lots of informative on any topics...... nice job keep it up !!.... term papers