Critical Masses Technology, Inc.

In my previous installment I discussed the simple framework for a client validation framework that works in the Notes client and the on the web using a common codebase in Javascript. The implication, of course, being that the validation is client-side and only has to be written once. The framework is skeletal and does not represent a functionally complete example, although it can be made to be.

Now, on the web, simply calling the submit() method of your form object performs a POST request back to the server with all the form data. Overriding the onSubmit() event of the form object with your own code and a return value of true or false will either prevent or allow the submit() to occur, much the same way that the Querysave event of a Notes form can be made to arrest the save event by setting the continue parameter variable to false. While this parallelism is striking, the caveat is that you cannot directly call the submit() event of the form in Javascript in the Notes client.  So how does one initialize the whole chain of events that would lead to a form being submitted for both a Notes client and a web form? Well, the good news is that the Javascript onSubmit() event’s return value will affect the chain of events in the Notes client (in Notes, things are not always as they seem…) so at least we can rely on our validation code executing as a result of being called from the event to stop a submit from occurring if a validation fails. Here’s where we need to step out of the Javascript box to perform the final steps. The only way to initialize a save in both the Notes client and on the web is to call the function @Command([FileSave]). On the web, this will fire the submit() event of the form which will in turn fire the onSubmit() event, calling our code and affecting the execution of the save() event based upon its return value (true or false.) In the Notes client, the same thing will happen, except for one important difference: On the web, a submit intrinsically results in a new URL being loaded, which can be served up to the browser from a $$Return field (old school) or a Webquerysave agent. In the Notes client, however, the open form will not close. Simple, you say? just add a @Command([FileCloseWindow]) to the macro? Well, that will result in the user being prompted if they want to save their changes in the Notes UI –not exactly desired behavior after all our validation ran. The answer, again, is an old-school trick of using the Postsave Notes form event to force the close:

Sub Postsave(Source As Notesuidocument)
    source.Document.SaveOptions = 0
    Call source.Close
End Sub

Setting the reserved field “SaveOptions” to zero (note that the field does not have to be present in the form and in fact will present less of a problem if it isn’t) tells the Notes client that the user shouldn’t be prompted to save the changes made, which is desirable to use as we’ve already just saved the document.

That’s it! My evolved thinking on this whole process is that despite the laudable inclusion of Javascript in the Notes client since R5, the implementation is barely practical but workable. A unified development strategy from Lotus has been long in coming and looks to be here with XPages. The skinny on XPages is that it’s a J2EE development model for Notes that adheres to the MVC (Model View Controller) paradigm. The beauty of XPages is threefold:

1. If you are familiar with J2EE and JSF development, XPages, being a JSF implementation, will seem natural to you.
2. As the view is architecturally separate from the model and controller, it can be rewritten to support various clients and technologies. Presently, the view has only been written for the web, hence XPages’ limitation to web browser implementations at the moment. Rest assured, though, that IBM is putting the finishing touches on a Notes client view implementation that will provide complete fidelity (we hope) of your application to the client. Finally, true write once and deploy anywhere for Notes developers!
3. Being implemented in the J2EE space brings a modern development environment to the long in the tooth Notes dev world. Finally, the full power of a modern IDE and a modern programming model is within our reach. Notes developers can drop in Javascript libraries at will and create custom components. Things web developers have taken for granted for quite some time

With new technologies come new possibilities. This is a double edge sword. Those expecting XPages development to be a simple one-to-one mapping of functionality from current Notes dev practice will be shocked. The strict binding of controls to documents is gone, as is the relative simplicity that comes from what is -after all- a very simplistic development model. The depth and complexity of XPages may be daunting, but it does represent the future of Notes.

As always, feedback is appreciated.