API

The Jaxer server framework contains functions and code that run only on the server.Below is a listing of all classes in the Jaxer Framework namespace. Click on a class to visit its documentation.

A collection of Jaxer extensions for the JavaScript Function object.
2. JSON
An object that exposes native functions for constructing and parsing JSON data strings. A synonym for Jaxer.Overrides.JSON.
3. Jaxer
The Jaxer namespace.
Class for the current app’s metadata.
Network socket utility object for simple binary socket access.
A namespace object holding functions and members for in-memory caches.
Callback namespace for remote functions.
A namespace object holding functions and members for preparing the callback data at the end of page processing that will allow the page to call back its server-side functions.

9. Jaxer.ClientError

An error that can be thrown on the client during a callback.
Namespace containing the config properties.
Container object that is used for all types of containers (e.g. session, sessionPage, etc).
A namespace object holding functions and members used to handle the events fired from the Jaxer Core into the Jaxer Framework.
The namespace that holds functions and other objects for working with a database.
Namespace that holds the MySQL implementation of the Jaxer DB API.
Creates a new connection to the given databaseName (file).
Contains the returned value of a SQL query.
Namespace that holds the SQLite implementation of the Jaxer DB API.
Creates a new connection to the given databaseName (file).
A database-based persistor for Jaxer Container objects (session, sessionPage, etc.)
Utility object for filesystem directory access.
This is a utility class that wraps XPCOM directory/folder utility functions.
Exception used by the Jaxer framework.
A container for all the loaded extensions to the Jaxer framework.
Utility object for simple filesystem access.
This is a general class that wraps XPCOM filesystem functionality and from which File and Dir objects are derived.
File System Object contains methods useful for accessing the basic file and directory objects.
Encapsulates function information needed for generating client-side proxies and for server-side storage of functions used in callbacks.
Namespace object holding functions and members used to get and include HTML and JavaScript from external sources.
Log is a static object meant to be shared across the framework and perhaps even the user’s code. In a module, use it to create a module-specific logger and then log with it.
Base class of all Appenders: listeners that know how to append log messages somewhere, e.g. to a file or a database.
Appends log messages to the same file as the Jaxer core.
File-based Log Appender.
Logging level object used by the Logging facility to set or determine the current log levels.
Object created by the global Log.forModule(“…”) method for module-specific logging.
This is a utility class that wraps XPCOM Network utility functions.
Namespace used for overriding some of the built-in JavaScript and JavaScript-environment (user-agent) functions that may not make sense or need to behave differently on the server.
An object that exposes native functions for constructing and parsing JSON data strings. A synonym for window.JSON.
Used to execute operating system processes.
An instance of this object has the lifecycle of the current request and contains information about it.
40. Jaxer.Request.ACTIONS
Container for information about uploaded files.
Current response and its associated information.
A namespace object holding functions and members used for sending emails via SMTP (Simple Mail Transfer Protocol).
A structure holding email message information.
The Class describing a Sandbox: a container that can load a server-side window with its own DOM, and executes JavaScript server-side, but is more protected than the regular Jaxer server-side window.
Options used to define the behavior of Jaxer.Sandbox opening.
Container object used during runat attribute and property processing.
This class processes script elements to determine which of its functions fall into the various runat categories.

49. Jaxer.SendOptions

This is the namespace that contains Jaxer serialization methods. The Jaxer serializer uses the familiar and popular JSON format. However, additional functionality has been provided to allow for serialization of more complex data structures. Specifically, this module supports cyclical data structures, multiple references, and custom typeserializers. Each of these is described below. Cyclical data structures occur when an object (or array) contains a descendent structure that also references that same object. For example, a DOM node has references to its children and these children also have references to the DOM node (their parentNode). In a traditional JSON environment, if you were to try to serialize this structure, you would end up in an infinite loop or an exception would occur as the serializer traversed the parent node, its child nodes, and then back up to the parent node through the child’s parentNode property. Indeed, the serializer couldn’t get past the first child in this scenario. The Jaxer serializer bypasses this via the use of marker properties and specially formatted strings referred to as “references”. Multiple references are similar to cyclical data structures in that an object is referenced two or more times. However, this does not necessarily create a cycle. For example, say you have the following code:

var car = { color: "blue", price: 10000 }; var cars = [ car, car ] ;

As you can see, the same car object has been referenced twice in the array. In a traditional JSON serializer, each instance of car would be serialized separately. Unfortunately, that alters the data structure that will be accessed after deserialization in a subtle way. You will end up with two independent car objects which means that changing the price of one will not change the price of the other as would have happened before the serialization/deserialization cycle. In order to restore the same references, Jaxer serializes the car only once and then leaves placeholders to point to that single instance. During deserialization, the placeholders are replaced with actual references to the deserialized object, thus restoring the original data structure as it appeared before serialization. Some data types cannot be expressed in JSON. For example, the Date type is not listed as a valid type in JSON. So, in order to support this type and potentially many others, the serializer allows the developer to register custom serializers and associated deserializers for a given type. When the serializer sees these types, the custom handlers are used to convert the item to a string. It is then the responsibility of the custom deserializer to restore the string to the original type. For example, Jaxer supports XMLDocuments. The custom serializer creates an XML string which is specially tagged so the deserializer can restore the XML string back to an XMLDocument. Next, we briefly discuss how Jaxer recognizes cycles, multi-references, and how it represents references and custom serialized objects. The Jaxer serializer makes an initial pass over the data being serialized. Each object, array, and custom serialization object is tagged with a unique index. (Note that some objects do not allow properties to be added to them. In this situation, the Jaxer serializer maintains an array of these items. This array is searched when new items are encountered and serves the same purpose as the id property). Before adding the index, we first check if we have already indexed the item. If the tag already exists, then we’ve either exposed a cycle or a multi-reference. At this point, the serializer knows to switch to another JSON format that minimizes the amount of data to be serialized. References and custom serialization objects each make use of specially formatted strings. To make this a bit clearer, we create an array of two references to the same date object.

var d = new Date(); var items = [ d, d ] ; var json = Jaxer.Serialization.toJSONString(items);

The resulting JSON string will look like the following:

 [ [ "~1~","~1~" ] , "~Date:2007-08-17T11:57:30~" ]

This format always has a top-level array whose first element is the root item that was originally being serialized. In this case, our top-most element was an array. As an aside, the only top-level elements that can generate this format are arrays, objects, and custom serialization objects. The first special format used for references and is defined with “~ # ~” where # is a number. The number is the index into the top-level array. The element at that index is the item that needs to be referenced where the reference string lives. In this example, once deserialization has completed, both instances of “~1~” will have been replaced with references to the deserialized date object. The next custom format, the date, shows how custom serializers emit text. The first item after the ~ but before the : is the name of the type. This is the fully-qualified type as you would have to type it in JavaScript to get to that type’s constructor. The string after the : is in a format as generated by the type’s custom serializer. The resulting string generated by the custom serializer is in turn serialized as a string, so the deserializer does not need to handle special characters or escape sequences. It is the responsibility of the custom deserializer to consume that text and to return effectively a clone of the original object. This module also allows a developer to register alternate top-level serialization and deserialization methods. The default method for serialization is ‘nativeJSON’ which attempts to use the built-in JSON support in the user agent, when available. In cases where ‘nativeJSON’ is not supported, the ‘JSON’ mode will be used. The developer can also use ‘JSON’ along with more options to customize serialization for special values like ‘undefined’, and ‘INFINITY’, for example. Finally, there is a ‘Jaxer’ mode as described above. This mode is used by Jaxer’s framework and callback mechanisms and is available to developers that may need this advanced functionality. These serialization methods are specificed in a separate optional parameter to the “toJSONString” and ‘fromJSONString” functions. Note that if the developer uses a non-default serialization method, then the developer is also responsible for using this same method for deserialization. Currenty, this implementation cannot detect which method was used for the original serialization step.

A namespace object holding functions and members used to manage a user session across multiple requests.
Network socket utility object for simple character-based (non-binary) socket access.
Namespace object holding functions and members used to access operating system resources and processes.
A namespace object used to access threading-related functionality, such as async processing.
A namespace to hold a miscellany of generic utility functions and other objects. In particular, it also holds sub-namespaces for more specific operations.
Namespace used to hold functions and other objects for using CRC32.
Namespace used for handling information related to SSL certificates.
Information about an SSL Certificate.
Namespace object holding functions and members for working with client (browser) cookies on the server side.
Namespace used to hold functions and other objects that extend JavaScript’s DOM capabilities.
Namespace used to hold functions and other objects that extend JavaScript’s datetime handling.
Namespace used to hold functions and other objects that extend JavaScript’s math capabilities.

Namespace used to hold functions that create and manipulate a hash whose values are primitives or Arrays of primitives.

The namespace that holds functions timing javascript.
Namespace that holds functions and other objects that extend JavaScript’s string capabilities.
Namespace that holds functions and other objects for working with URLs.
An object describing the parsed pieces of a URL.
Namespace object holding functions and members used to resolve and fetch web resources. Fetching is done via XMLHttpRequests.
69. Jaxer.Web.ACTIONS
Namespace to hold the Jaxer client-side cross-browser wrapper around XMLHttpRequest.
A hashmap containing detaild information about the response from an XHR.send.
Options used to define the behavior of Jaxer.XHR.send.
73. Jaxer.defaults