Page Lifecycle

The lifecycle of a page has three stages:

processing the initial page request on the server
rendering the page's initial HTML in the browser
processing any number of proxied functions to the page on the server

Process

When a page is requested, the page is loaded into Jaxer on the server and is parsed into a document object model, or DOM. This DOM (which we'll refer to as DOM1) may be transformed using Javascript and the Jaxer API and is then serialized as a page, returned to the browser, and discarded. This initial DOM is never rendered to the screen as it has no visual representation in Jaxer on the server.

The browser then parses the page into its own DOM, DOM2, and renders the page to the screen. Scripts in the page of the browser may then call back to the original page at the server.

When a proxy function is called, the server provides a new, empty DOM (DOM3). The proxy function can return data including any serialized portion of its DOM, which may then be programatically injected into the DOM of the page in the browser (DOM2).

The DOMs of these three phases are separate, are not synchronized, and do not directly interact, which reduces the memory footprint of your application.

The only DOM which endures among these three stages is DOM2, the DOM in the browser window.

Lifecycle in Detail

Standard Page Flow

Flow with Callback/Proxied Functions

Stage 1: Server Handles a Page Request

The page request from the browser is received by the web server, which fetches the appropriate HTML document (either from the file system or perhaps from another "handler" such as PHP or Ruby or Java).
It then feeds the document to Jaxer, which begins to parse the HTML document. As it does so it builds up the DOM tree.
When it encounters <script> tags it not only adds them to the DOM but may also execute them if they have a runat attribute that indicates they should run on the server.
During the parsing and execution, external content may also be fetched and loaded into the document, via <script src="..."></script> elements and Jaxer.load(...) for JavaScript code, via <jaxer:include src="..."></jaxer:include> (or <jaxer:include path="..."></jaxer:include>) for HTML content, or via XMLHttpRequests for any content.
After the DOM is fully loaded, the onserverload event is fired. This is the server-side equivalent of the onload event in the browser. It's named differently so your code can react separately to onserverload and onload events.
Jaxer post-processes the DOM, removing <script> blocks meant only for the server, replacing functions to be proxied with proxy calls, saving (as needed) functions that should be available on proxy calls, and so forth.
Finally, the DOM is serialized back to HTML, which is delivered via the web server to the browser.

Stage 2: Browser Processes the Response

The browser begins to parse the HTML, building up the DOM.
When the browser encounters <script> tags it not only adds them to the DOM but also executes them.
External JavaScript code or any other content might also be loaded.
The onload event fires.

The page is progressively rendered throughout much of this flow, and the user can interact with it.

Stage 3: Server-side Proxy functions

When Jaxer receives such a request, it creates a new, empty document unless you specify a different static document as a parameter.
It retrieves the saved functions marked for availability during proxy function calls to this page.
If a function called oncallback is found, it is executed. This is usually used to create the environment needed, such as loading and preparing Javascript libraries.
The callback function itself is executed.
Finally, the result of that execution—the return value, if the function sends one—is packaged and as the response to the request.

Again, note that although DOM3 is available within the execution of a proxy function, it is not serialized as HTML nor returned as the response, as is the case during the regular (non-proxied) page processing flow.

Detailed Lifecycle Code Example

To try this on your computer, put the first code segment into an HTML file, the second into a file named autoload.js and the third into loadTestFile.js, with all three files in the same directory.

<html>
	<head>
		<script type="text/javascript" runat="server">
			// we'll use this to track how many times
			// oncallback is executed
			Jaxer.session['counter'] = 0;
		</script>
			
		<script type="text/javascript" runat="both" src="autoload.js" autoload=true></script>
	
		<script type="text/javascript" runat="server">
			Jaxer.Log.info('At the top of the server-side script block');

Jaxer.Log.info('Outside any functions and at the end of the server-side script block');
		</script>
		<script type="text/javascript" runat="client">
			clientLogProxy('At the top of the client-side script block');
			
			// because testing() has turned on its proxy it will execute from the client
			testing();
			
			// since serverCallableOnly cannot be called from the client,
			// the next two lines would not be executed and if you uncomment them
			// you should see an error and none of this block's log messages would be written out
			// var dt = serverCallableOnly();
			// Jaxer.Log.info('Current client date is: ' + dt);

clientLogProxy('At the end of the client-side script block');
			clientLogProxy(''); // just a blank line for the log
		</script>
	</head>
	<body>
		<h1>Demoing the Jaxer Lifecycle</h1>
		<h2>a/k/a the Execution Sequence</h2>
	</body>
</html>

Autoload.js Contents

// the log line is written on every call
Jaxer.Log.info('');
Jaxer.Log.info('Inside autoload.js');

// the alert pops up as normal when called from the client
// but is written to the log when called from the server
alert((Jaxer.isOnServer) ? "On the Server":"On the Client");
Jaxer.Log.info('');

LoadTestFile.js Contents

// since this is only called server-side,
// the alert is actually written to the log file
alert('Inside loadTestFile.js');