On some system configurations, an error may be logged during startup when Jaxer tries to determine the location of the home folder. This may be caused by an invalid or erroneous setting for the HOME environment variable. Make sure that the HOME environment variable references a location that is both a valid folder and is accessible to the user running jaxer. This error can be ignored however further attempts to use the Jaxer.System.homeFolder property will result in the same exception appearing in the logs and the Jaxer.System.homeFolder value will be null.

Jaxer currently will not load images server side, this means canvas actions such as drawIimage will throw an exception. This is being tracked in ASAP ticket jxr-172

This has been addressed in Jaxer 0.9.6 and later.

To work around the issue.

use

db.execute("insert into user_roles (user_role_id,access_role_id) values(?,?)"
, db.defaultConnections[Jaxer.DB.DEVELOPER].lastInsertId,3);

Functions defined on the server that have their proxy property set to true (e.g. by being in a script block with runat="server-proxy", or by directly setting their proxy property) are automatically made available in the page served to the browser. The original function definitions are stored on the server for use during callbacks. So are any functions on the same page that they could have called: basically any functions that were not explicitly set to runat="server-nocache".

Jaxer brings client-side technologies and paradigms to the server — quite literally. Every HTML (and PHP) document will be parsed and "executed" by Jaxer on the server prior to being re-serialized and sent to the client. Of course, any JavaScript not designated to be run on the server will not be executed in Jaxer. However, all HTML and CSS content will be used to create the DOM just as it would in a browser. Several current limitations of Jaxer arise from this fact.

When you set an event handler server-side on a DOM element within HTML, e.g.

<input type="checkbox" id="chk1" onclick="foo()">

the DOM will have an onclick attribute with value "foo()" and that will be properly serialized back to HTML by Jaxer before it's sent to the client.

However, if you have server-side code that instruments or "scripts" the DOM, as in

<script type="text/javascript" runat="server"> document.getElementById("chk1").onclick = foo; </script>

the event handler is created but the DOM "onclick" attribute is not. (This is standard browser behavior.) Therefore, when Jaxer serializes the DOM for sending to the client, the checkbox DOM element will not have an onclick handler, and foo will not be called on the client.

To simplify using DOM scripting to instrument the DOM, e.g. to separate the code from the presentation, Jaxer provides a function that does so correctly both server-side and client-side:

<script type="text/javascript" runat="server"> Jaxer.setEvent(document.getElementById("chk1"), "onclick", "foo()"); </script>

Since server-side there is no user to interact with, it's not clear what functions like alert(), prompt(), and confirm() should do. So Jaxer overrides them with a different implementation which logs their output to the Jaxer log, at the "INFO" level. Try it!

Frames and iFrames are not currently loaded server-side by Jaxer. They require creating DOMs within the DOM, and even if Jaxer were to do this, it's not clear what DOM it should serialize and stream to the client. As a result, we felt it best that frames and iframes are not loaded at all server-side; they are left to the browser to load. (Perhaps this isn't a limitation at all but the desired behavior?)

The title of a document may be set statically by providing a element in the area of the document. But what if you want to set it programatically? Setting document.title = "..." may work client-side, but since it does not change the DOM, it will not work server-side. To this end, Jaxer provides a convenience function which works both server- and client-side, and (as far as we've tested) across browser vendors. Simply use Jaxer.setTitle("...") in your code.