Scheduling

And from this it is only a small step to scheduling, i.e. submitting a serverFrame after another serverFrame has returned. We illustrate this with . First, we set the filterstring interactively, by adding an input box for the MapServer regular expression. The contents of that inputbox are copied to the "qstring" variable in the s2 serverFrame when this is submitted. When typing /F.*/ here, only countries with a capital F in their name will be returned in the list. The returned extent will be computed on the basis of these countries only, but the map is still that of the whole world. To get a map with only countries within the computed extent, the extent of the s1 serverFrame has to be set to the extent returned by s2. This can of course only be done after s2 has returned and placed its results in s4, ergo by s4's onReturn function "displayQuery()". This copies the returned extent to the "mapext" variable of s1, and submits that serverFrame. When the results of that second request have been put into s3, the map is displayed .

There is a more sophisticated way to synchronize web requests. A serverFrame without an "execURL()" address but with an "onReturn()" function can serve to synchronize regular serverFrames. This is done by using the serverFrame method "scheduleAfter()". In a fifth serverFrame is defined with an onreturn function "displayAll()" that displays both the image and the table from s3 and s4. This serverFrame is scheduled after s3 and s4, i.e. it will execute its "onReturn()" function after both s3 and s4 have returned. No "onReturn()" function for s3 is needed any more, and the one for s4 just requests a map based on the extent of its table, but doesn't display it. Only after both have returned, "displayAll()" is automatically executed to display both table and map .

This is a highly promising facility. Any set of serverFrames can be scheduled after any other set, including other scheduling serverFrames. Think about multi-database queries, or visualization applications like . It is also very experimental; the scheduling mechanism is very simple, and I don't know if there are possible race conditions. Don't use it for mission critical production environments yet.