Domino's Computational Order
There's something I've never really truly understood about the way Domino computes stuff and that's the order in which it does it. Say, for example, you open a webpage, which has a WebQueryOpen Agent and lots of computed for display fields. In what order do all the fields compute? Is it always after the WQO has run? If there is a strict, defined order in which events are triggered why have I never seen or read about it?
It's something I've been thinking about on and off for a while now. It was brought back to light for me by a bug I've just had to fix. The problem was that you can't use a Computed Subform if it's computation relies on the results of a WebQueryOpen Agent, as the subform is computed before the WQO can set any field values. This took me hours of messing about to discover!
In fixing this bug I found another confusing behaviour. Say the form has a Computed for Display field on it, which has its own name as its value and the real value is set by the WQO agent. I've found that relying on this value being there for reference by other Computed for Display fields is not always possible.
So, does anybody know the order in which computations are performed?
Skip to the 
You can subscribe to an individual
Appendix C-5 in "Performance Considerations for Domino Applications" IBM RedBook has some information about the order of execution, but it's handling the Notes applications, not web applications.
- Johan
I have never seen it documented, I guess IBM counts on the secondary documentation market.
What I have always thought:
1. Computed, and default values
2. Subforms
3. WQO
Browser apps lack a server-side postopen event which can be useful. Out of curiosity, why not use computed fields instead of computed for display? I too have had alot of odd behavior with CFD fields so I only use them with Notes client development.
The link to the RedBook is:
{Link}
Also ComputedText evaluates after WQO Agent runs.
It's easy enough to deduce the order via an experiment. Simply calculate anything on a form that can possibly calculate, and make the value include the current time - down to the .01 of a second. Then, just sort them by time order. Yeah, it's clunky. But, it's empirical!
If you do it, please post the results. I'm curious. (And, a bit short on the time to do it myself.) :)
There was an article on Notes.net about this, way back in the day when Domino was just getting added to Notes. I think Bob Congdon wrote it. I can't find it on dW, though.
I did come across this while searching, though:
{Link}
Users interact with Domino applications through commands issued as URLs. Each command specifies a top-level object and activates the methods needed to carry out a request and generate HTML output. The Domino Web Server implements many commands. The commands related to the display and modification of documents are worth a closer look. These are the commands that enable interactive applications, so the similarities and differences in their implementation are of particular interest.
Three commands display the contents of a document:
?OpenDocument opens an existing document in read mode, ?EditDocument opens an existing document in edit mode, and ?OpenForm opens a new document in edit mode. The implementations of ?OpenDocument and ?EditDocument are very similar. Both execute the following sequence of steps:
1. Opens the existing document.
2. Reads all items from document into memory.
3. Loads the Notes form referenced by this document.
4. Scans the Notes form and executes default value formulas for any items that are not yet in memory, and executes all computed field formulas and add/update items to the in-memory document accordingly.
5. Runs the appropriate agent if an item named $$QueryOpenAgent exists.
6. Renders the Notes form into an HTML page or HTML form using the item values from the in-memory document.
7. Frees the in-memory document and all items it contains.
The only significant difference between ?OpenDocument and ?EditDocument commands is in step 6, where ?OpenDocument instructs the GenerateHTML methods to respect read-mode hide attributes contained within the Notes form, and to create HTML for a read-only page. ?EditDocument instructs these methods to respect edit-mode hide attributes on the Notes form and to create an HTML form.
The ?OpenForm command executes a similar sequence of steps:
1. Creates a new document in memory.
2. Loads the Notes form referenced in the URL.
3. Scans the Notes form and executes all default value formulas and computed field formulas, adding items to the in-memory document.
4. Runs the appropriate agent if an item named $$QueryOpenAgent exists.
5. Renders the Notes form into an HTML form, respecting edit-mode hide attributes and using item values from the in-memory document.
6. Frees the in-memory document and all items it contains.
The last step of the procedure for all three commands frees the in-memory document and its associated items. The ?EditDocument and ?OpenForm commands do not cache the documents for later use because that would violate the stateless nature of the a Web server. If and when the browser sends edited information back, the Domino Web Server will re-establish all the data structures necessary to handle the updates. ?CreateDocument and ?SaveDocument are the two commands that receive HTTP POST data generated by browsers when a user presses the Submit button on an HTML form and saves the data in Notes documents. Submit buttons on HTML forms generated by the ?OpenForm command send the ?CreateDocument command, and Submit buttons on HTML forms generated by the ?EditDocument command send the ?SaveDocument command. The two commands follow similar sequences of steps. The steps for ?CreateDocument begin with:
1. Creates a new document in-memory.
2. Opens the Notes form referenced in the URL.
3. Scans the Notes form and executes all default field formulas and computed value formulas, adding items to the in-memory document.
The steps for ?SaveDocument begin with:
1. Reads the existing document referenced in the HTTP POST data.
2. Opens the Notes form referenced in the URL.
3. Scans the Notes form and executes all default field formulas and computed value formulas, adding items to the in-memory document.
Then both commands continue on essentially the same path:
1. Creates items for all data sent in the POST data.
2. Scans the Notes form and executes all translation, validation and computed value formulas, updating items in the in-memory document and returning validation errors as HTML.
3. Scans the Notes form and eliminates any computed-for-display items from the in-memory document.
4. Runs the appropriate agent if an item named $$QuerySaveAgent exists.
5. Saves the in-memory document to the appropriate database file.
6. If the $$Return item exists, runs the appropriate formula from the Notes form, and if there is no output from a QuerySave agent, sends the result of this formula back to the browser.
7. Deletes the in-memory document and all associated items.
One thing worth noting is the fact that formulas that a user might have thought executed only once at the time that an HTML form was sent by either the ?EditDocument or ?OpenForm command will actually execute again when ?CreateDocument or ?SaveDocument is processed. This can result in some confusion if these formulas have time-dependent values, or are based on lookups of constantly changing information.
If i use a WQO-Agent, i ever reference to the session.DocumentContext - so the whole document is loaded and computed before, then the WQO-Agent fires. Anyway we were not able to reference to any computed items on the current doc.
I've always believed that the event name was wrong. If they'd called it WebQueryService (which it is, really), there would be a lot less guessing involved. WQO seems to indicate some sort of kinship to the Notes QO event, and that's just not the case.
Thanks guys. That helps and I think I understood it more now. Although I'm surprised there doesn't seem to be a definitive guide to the exact order of things. Is some of it still down to guess-work?
I've read that calculated field are computed from the top to the bottom of the document
I have a WebQueryOpen agent that does not work on the server but it does work locally.
Dim s As New NotesSession
Dim doc As NotesDocument
Set doc = s.DocumentContext
doc.test = "someprefill"
After reading through the above it doesn't seem to make any sense because it works in different locations.
The field doc.test is an editable field so no problems with computed fields here.
Any ideas?
Problem solved - database corruption!!! Or some such other silly error that has cost me days! I deleted the database on the server and did a new replica. That solved the problem.