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.
jaxcentPagerefers to an object of type
JaxcentPagethat 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
jaxcentPageneeds to be declared public.
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
JaxcentPageobject in the page constructor will work fine. But trying to instantiate the
JaxcentPageobject 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
in the .aspx page.
If using this second method, there is no need to make the
JaxcentPage object public.
does handle virtual directories correctly (for a typical deployment), by emitting
(instead of simply
/JaxcentDotNet23.js) when deployed in a virtual directory.
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
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.
JaxcentDotNet23.js includes the actual URL for the JaxcentHandler.ashx, and will need to be
updated if the URL changes. In the other direction,
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
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