Jaxer Framework Index

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.

Class Jaxer Server Framework Jaxer Client Framework
A collection of Jaxer extensions for the JavaScript Function object
1.0 no
The Jaxer namespace.
1.0 1.0
Class for the current app's metadata
1.0 no
Network socket utility object for simple binary socket access.
1.0 no
Callback namespace for remote functions.
no 1.0
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.
1.0 no
An error that can be thrown on the client during a callback
1.0 no
Namespace containing the config properties.
1.0 no
Container object that is used for all types of containers (e.g. session, sessionPage, etc).
1.0 no
A namespace object holding functions and members used to handle the events fired from the Jaxer Core into the Jaxer Framework.
1.0 no
The namespace that holds functions and other objects for working with a database.
1.0 no
Namespace that holds the MySQL implementation of the Jaxer DB API.
1.0 no
Creates a new connection to the given databaseName (file).
1.0 no
Contains the returned value of a SQL query.
1.0 no
Namespace that holds the SQLite implementation of the Jaxer DB API.
1.0 no
Creates a new connection to the given databaseName (file).
1.0 no
A database-based persistor for Jaxer Container objects (session, sessionPage, etc.)
1.0 no
Utility object for filesystem directory access.
1.0 no
This is a utility class that wraps XPCOM directory/folder utility functions
1.0 no
Exception used by the Jaxer framework.
1.0 no
Utility object for simple filesystem access.
1.0 no
This is a general class that wraps XPCOM filesystem functionality and from which File and Dir objects are derived.
1.0 no
File System Object contains methods useful for accessing the basic file and directory objects.
1.0 no
Encapsulates function information needed for generating client-side proxies and for server-side storage of functions used in callbacks.
1.0 no
Namespace object holding functions and members used to get and include HTML and JavaScript from external sources.
1.0 no
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.
1.0 no
Base class of all Appenders: listeners that know how to append log messages somewhere, e.g. to a file or a database.
1.0 no
Appends log messages to the same file as the Jaxer core.
1.0 no
File-based Log Appender.
1.0 no
Logging level object used by the Logging facility to set or determine the current log levels.
1.0 no
Object created by the global Log.forModule("...") method for module-specific logging.
1.0 no
This is a utility class that wraps XPCOM Network utility functions
1.0 no
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.
1.0 no
Used to execute operating system processes
1.0 no
An instance of this object has the lifecycle of the current request and contains information about it.
1.0 no
Container for information about uploaded files.
1.0 no
Current response and its associated information.
1.0 no
A namespace object holding functions and members used for sending emails via SMTP (Simple Mail Transfer Protocol).
1.0 no
A structure holding email message information.
1.0 no
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.
1.0 no
Options used to define the behavior of Jaxer.Sandbox opening.
1.0 no
Container object used during runat attribute and property processing.
1.0 no
This class processes script elements to determine which of its functions fall into the various runat categories.
1.0 no
1.0 1.0
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 serializers. 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 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 gets around this via 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. 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 serialization instance. During deserialization, the placeholders are replaced with references to the deserialized object, thus restoring the original data structure. 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 item to its original structure, as appropriate. 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 serialization and deserialization methods. The default method as described above is referred to as the "jaxer" method. Alternately, if you require strict adherence to pure JSON, you can use the "json" method. The method is specificed in a separate optional parameter to the "toJSONString" function (see that function for more details).
1.0 1.0
A namespace object holding functions and members used to manage a user session across multiple requests.
1.0 no
Network socket utility object for simple character-based (non-binary) socket access.
1.0 no
Namespace object holding functions and members used to access operating system resources and processes.
1.0 no
A namespace object used to access threading-related functionality, such as async processing
1.0 no
A namespace to hold a miscellany of generic utility functions and other objects. In particular, it also holds sub-namespaces for more specific operations.
1.0 1.0
Namespace used to hold functions and other objects for using CRC32
1.0 no
Namespace object holding functions and members for working with client (browser) cookies on the server side.
1.0 no
Namespace used to hold functions and other objects that extend JavaScript's DOM capabilities.
1.0 no
Namespace used to hold functions and other objects that extend JavaScript's datetime handling.
1.0 no
Namespace used to hold functions and other objects that extend JavaScript's math capabilities
1.0 no
Namespace used to hold functions that create and manipulate a hash whose values are primitives or Arrays of primitives
1.0 no
The namespace that holds functions timing javascript
1.0 no
Namespace that holds functions and other objects that extend JavaScript's string capabilities.
1.0 no
Namespace that holds functions and other objects for working with URLs.
1.0 no
An object describing the parsed pieces of a URL.
1.0 no
Namespace object holding functions and members used to resolve and fetch web resources. Fetching is done via XMLHttpRequests.
1.0 no
Namespace to hold the Jaxer client-side cross-browser wrapper around XMLHttpRequest.
1.0 1.0
A hashmap containing detaild information about the response from an XHR.send.
1.0 1.0
Options used to define the behavior of Jaxer.XHR.send.
1.0 1.0
1.0 1.0