Jaxcent for .NET

Hooking up Jaxcent Code-Behind

Because the IDE does not know about Jaxcent, the Jaxcent code-behind hookup has to be done by the programmer.

If you have gone through Getting Started with Jaxcent using C# or Getting Started with Jaxcent using Visual Basic documentation and have done the coding suggested in there, you are already familiar with the basics of hooking the code-behind.

Details are provided below.

Items added by the "Add New Item"

  The JavaScript file, JaxcentDotNet23.js

This is added by the Jaxcent "Add New Item".

  The ASHX handler for Jaxcent, JaxcentHandler.ashx

Also added by the Jaxcent "Add New Item".

  Reference to Jaxcent

The Jaxcent "Add New Item" a reference to Jaxcent DLL as well.

The JavaScript include statement

Every ASPX or HTML file that is using Jaxcent, needs to have the JavaScript include statement.

  ASPX files

For ASPX files, it is of the form
    <script type="text/javascript" src="JaxcentDotNet23.js?jaxcentid=<%= jaxcentPage.JaxcentConnectionID %>"></script>
where jaxcentPage refers to an object of type JaxcentPage that has been instantiated in the regular (C# or VB) code-behind page of the ASPX file. In order that the above code be able to access jaxcentPage, jaxcentPage needs to be declared public.

The JaxcentConnectionID is how the ASPX page is connected with a particular instance of the page in a browser.

Note that the reference to "JaxcentDotNet23.js" may need to be adjusted to "../JaxcentDotNet23.js" or "../../JaxcentDotNet23.js" etc. if the HTML and/or ASPX files are arranged in a hierarchy. It is not recommended that absolute reference "/JaxcentDotNet23.js" be used, as this will require changing it everywhere for deployment in virtual directories. Relative references can be kept as they are, and still work in virtual directory deployment.

There is a second method of wiring ASPX pages for Jaxcent - this involves using one of the JaxcentPage constructors that accept an ASPX page object as a parameter. For instance,

    JaxcentPage jaxcentPage;                         // C# declaration
    jaxcentPage  = new JaxcentPage(this);            // C# ASPX page constructor - "this" is an ASPX page

    Dim  jaxcentPage As New JaxcentPage(Me)          ' VB declaration - "Me" is an ASPX page

This method of hooking up Jaxcent is simpler, but does require more care. These constructors actually simply write out the necessary JavaScript include statement to the HTML output of the ASPX page. Therefore, it is important that this must happen no later than the ASPX "pre-render" event. Adding a page constructor and instantiating the JaxcentPage object in the page constructor will work fine. But trying to instantiate the JaxcentPage object in the Page_Load - where it is common to write initialization code - will not work, because at the time of Page_Load, the HTML output has already been written out.

Also note that this method will not work without a runat server form present, so if you remove the initially generated ASPX markup, you have to put in at least an emtpy

<form runat="server"></form>
in the .aspx page.

If using this second method, there is no need to make the JaxcentPage object public. While the emitted JavaScript uses an absolute rather than a relative reference, this method does handle virtual directories correctly (for a typical deployment), by emitting /<virtualdirectory>/JaxcentDotNet23.js (instead of simply /JaxcentDotNet23.js) when deployed in a virtual directory.

  HTML files

For HTML files, the JavaScript include statement is of the form
    <script type="text/javascript" src="JaxcentDotNet23.js"></script>
In this case, there is a further task that needs to be done. The Jaxcent framework needs to be told "If this HTML file is served, use this particular class to handle it."

The class that is written to handle it, must derive from JaxcentPage. It must also be connected to the the HTML page. A convenient method of doing this is in the Application_Start of the Global.asax page.

Connecting the HTML to the class is done by calling the AddURL method of the Jaxcent framework, as shown in the Getting Started with Jaxcent using C# or Getting Started with Jaxcent using Visual Basic documentation.

Changing the names/locations of JaxcentDotNet23.js and JaxcentHandler.ashx

These two names/locations can be changed, though usually there should be no reason to change them.

JaxcentDotNet23.js includes the actual URL for the JaxcentHandler.ashx, and will need to be updated if the URL changes. In the other direction, if using the method of having JaxcentPage constructors write out the JavaScript include statement, the framework needs to be told the name of the JavaScript file (if it's not the default), via the JaxcentJavaScriptURL property.

Specifying use-session and auto-session properties

There are two important items that can be specified with Jaxcent hookups:
  use-session   Jaxcent provides its own sessions. Sessions are not provided for pages by default. The programmer must indicate that a page needs access to the session object. This can be done by specifying use-session as true. This is available as a parameter in JaxcentPage constructors, as well as in the framework's AddURL methods.
  auto-session   Jaxcent also has the ability to automatically retrieve user input into sessions. This ability is not enabled by by default. The programmer must indicate that (i) a page needs access to the session object and (ii) the page needs automatic data retrieval. This can be done by specifying use-session as true, and in addition also specifying auto-session as true. The auto-session is also available in JaxcentPage constructors, as well as in the framework's AddURL method.