Once the page HTML is downloaded and the scripts start executing the page is created dynamically. This process is the same for all pages. The bulk of the work is done by the DBI built-in scripts especially base.js and extrastrict.js. Where these files can be found in the page is covered in the gist about the DBI page structure.
The screenshots included in this article are of the developer console in Chrome. It looks pretty much the same in Edge or Firefox or Safari.
Processing involves repreated calls to DBI REST endpoints exposed by the DBI server. This begins with a call to getsession. The server returns session information relating to the current page and user.
One of the bits of information in the returned object is the id of the project. This is used as a key to retrieve details of the project.
The next step is to access information about the content to be rendered for the page. This is done by calling the getbyids end point using the POST verb and including as the content a JSON key pair that is the UUID if the page to be rendered.
The content of the returned object is where most of the interesting stuff becomes available for processing by code in base.js. Amongst the properties of the object returned are those that deal with page events: loadingActions and readyActions. The readyAction object has been expanded to shows its content. script is one of the properties and contains the JavaScript code entered in the DBI backend and which will be injected into the browser.
Note the UUID of the page and shown in the screenshot below is just that of the 'current' or top-level canvas or dashboard control to be rendered. As this control is rendered, nested controls will be discovered and, as they are, this process will be repeated. You can see this in the list of REST calls made as there are several calls to the *getbyids
Scrolling back up the object for the top-level control shows there is a property called adapters. This is a list of all the visual elements (shapes, images, buttons, etc.) to used create the view.
You can see the first adapter is a sub-canvas. One of the properties is controlData which holds a stringified version of the object summmary. When loaded, the id of the sub-canvas is used to make another call to getbyids and so the process continues.
You can see each adapter has properties for the events it supports such a clickActions. There are no events in the example expanded but in others there will be entries either for implicit actions like changing a layer or explicit actions effected by a script. In the latter case the script will be stored in the property.
Calls are also made to an endpoint called getdata. The object returned represents a metric set. At the time of writing, how the ids for a metric set is selected has not been determined.