Improving Form Performance

Jake Howlett, 15 October 2001

Category: Forms; Keywords: performance return submit get post

When submitting a form, more often than not, we follow by redirecting the user to a new page. This new page can be created dynamically but this leaves little power over the look of the page. It is much better to redirect to another URL that points to a page or form that can be used to make the end result a lot more interesting. Alternatively, you can simply return the user to the view that shows the documents of the type on which they were just working, using a URL like the one below:

This works well. However it is not the most efficient method as we shall see.

A little known fact:

What happens when you submit a form to Domino? Well, assuming you have used a $$Return field formula or LotusScript Print statement that uses square brackets [] to tell Domino to redirect to a URL, then this is the chain of events:

The browser submits the HTML form to the Domino server.
The server processes the data and then evaluates the $$Return formula or runs the WebQuerySave agent to produce the redirection URL.
The server sends the redirection URL back to the browser.
The browser accepts the server data, detects that it is a URL, and requests the URL from the server.
The server gets the URL and sends the result of that request back to the browser.

We can verify this by using a Network Capture application like http://www.Ethereal.com to see the traffic involved in submitting a Domino form. Here is a shot of the data exchanged during the above scenario:

Starting with the first (highlighted) line we can see that the browser has used the POST method to send the form data to the server. The server then returns the 302 HTTP code to tell the browser the location of the requested object. This triggers a GET request from the browser back to the server for the second time.

Making it a little easier:

Obviously the above process involves one step too many. Luckily, if the URL you request is on the same server, Domino lets you skip this step. All you need to do is add double square brackets to the URL you want:

When Domino computes this formula it knows that you want to send the information contained in that page straight back to the browser. Here is what the packet capture looks like now:

Notice that there is one step missing from the previous example. This missing step means that the overall performance increases and the load on the server decreases.

Nothing is perfect:

As is always the case with Domino, it's not long before you start to find the limitations of features like these. Let's look at why this method is far from perfect.

The problem stems from the fact that the new page sent to the browser is the result of a URL like:



/development/jakeh/template.nsf/vwAS/109C767B988D8CEF80256A8F0068E8B7?EditDocument&Seq=1

So, the browser thinks this is the location it is at but the page returned from the server thinks of itself as being more like:



/development/jakeh/template.nsf/vwAS?OpenView

The first problem this causes is that any links on the new page that are relative point to the wrong place. This is particularly painful if you return to a categorised view. Try it for yourself and see what happens. You can of course fix this with the use of the "base href" method I discussed last week.

Another problem rears its ugly head if you use something like this method to return messages to the user. Any argument you tag on to the URL that you redirect to are lost.

Summary:

Having read this you are probably reluctant to start using it. To be honest, I've known about it for some time now and am yet to use it. It's just too limiting. Saying that though, it's definitely worth considering when you design your apps.

If you take nothing else away from having read this then I hope you have at least had an insight in to what happens in Domino's back-end as you post data. If this interests you then it is well worth downloading the Ethereal program I mentioned above. Then you can see for yourself what the packages I captured were.