Client-Side Script Caching

Using the DotNetNuke Client API

When using the Client API code in your application, you first want to check your .NET code to see if the client browser supports that functionality. If it does, you need to register the namespace scripts on the client as shown in Listing 10-1.

Listing 10-1: Verifying that a Client Browser Supports DHTML and Registering the Namespace

 If ClientAPI.BrowserSupportsFunctionality(ClientAPI.  ClientFunctionality.DHTML) Then       ClientAPI.RegisterClientReference(objPage, ClientAPI.  ClientNamespaceReferences.dnn) End If 

The first line of Listing 10-1, within the If statement, calls this function located within the ClientAPI class and passes it a value for the ClientFunctionality enumerator. This enumerator consists of the various client-side browser checks the class currently supports, shown in Listing 10-2. This enumerator is also located in the ClientAPI class.

Listing 10-2: Client-Side Browser Functionality Tests Supported

    Public Enum ClientFunctionality As Integer       DHTML = CInt(2 ^ 0)       XML = CInt(2 ^ 1)       XSLT = CInt(2 ^ 2)       Positioning = CInt(2 ^ 3)   'what we would call adequate positioning support       XMLJS = CInt(2 ^ 4)       XMLHTTP = CInt(2 ^ 5)       XMLHTTPJS = CInt(2 ^ 6)       SingleCharDelimiters = CInt(2 ^ 7)    End Enum 

The BrowserSupportsFunctionality function retrieves the client browser's major and minor build values. The value passed into the function is then compared against a list of supported browsers that are grouped by the enumerator names. The file containing this grouped list is named ClientAPICaps.config and it follows the basic XML version 1.0 structure, as shown in Listing 10-3. By default, ClientAPICaps .config is stored in the $Approot\Website\js\ folder. Isolating this file outside of the code was done for a good reason. There is always the possibility that a new browser or new version of an existing browser may be released to the public, and that it will support functionality contained within the current ClientAPICaps.config file. If it's a new type of browser, it won't be listed in the ClientAPICaps.config file. When a new browser or new version of a browser is released, there should be no need to require a recompile of the DotNetNuke or Web Utili projects. The only alternative to a recompile would be for developers and users to wait for the next release of DotNetNuke to add support for client-side functionality, which the framework is already capable of providing. Keeping functionality tests in a separate configuration file that can be edited with a text editor allows changes that can be made by almost anyone instead of waiting for another release or having to edit the code and recompile. This configuration file also offers DotNetNuke developers an easy way to extend and add functionality tests of their own.

Listing 10-3: ClientAPICaps.config File

 <?xml version="1.0" encoding=" utf-8" ?> <capabilities>    <functionality nm="DHTML" desc="Dynamic HTML">       <supports>          <browser nm="IE" minversion="4" />          <browser nm="Netscape" minversion="5" />          <browser nm="Gecko" minversion="1" />          <browser nm="Opera" minversion="7" />          <browser contains="Konqueror" />          <browser contains="Safari" />          <browser contains="FireFox" />       </supports>       <excludes>       </excludes>    </functionality>    <functionality nm="XML" desc=" Client Side XML Parsing">       <supports>          <browser nm="IE" minversion="4" />          <browser nm="Netscape" minversion="5" />          <browser nm="Opera" minversion="7" />          <browser contains="Konqueror" />          <browser contains="Safari" />          <browser nm="Gecko" minversion="1" />          <browser contains="FireFox" />       </supports>       <excludes>          <browser contains="Mac_PowerPC)" />       </excludes>    </functionality>    <functionality nm="XMLJS" desc=" Requires JavaScript Client Side XML Parsing">       <supports>          <browser contains="Opera" />          <browser contains="Konqueror" />          <browser contains="Safari" />       </supports>    </functionality>    <functionality nm="XMLHTTP" desc="Client Side HTTP Requests">       <supports>          <browser nm="IE" minversion="4" />          <browser nm="Netscape" minversion="5" />          <browser nm="Opera" minversion="7" />          <browser contains="Konqueror" />          <browser contains="Safari" />          <browser nm="Gecko" minversion="1" />          <browser contains="FireFox" />       </supports>       <excludes>          <browser contains="Mac_PowerPC)" />       </excludes>    </functionality>    <functionality nm="XMLHTTPJS" desc="Requires JavaScript HTTP Requests">       <supports>          <browser contains="Opera" />          <browser contains="Konqueror" />          <browser contains="Safari" />       </supports>    </functionality>    <functionality nm="XSLT" desc="Client Side XSLT Processing">       <supports>          <browser nm=" IE" minversion="4" />       </supports>       <excludes>          <browser nm="Netscape" minversion="6" />          <browser contains="Konqueror" minversion="5" />          <browser nm="Opera" minversion="7" />          <browser contains="Safari" />          <browser contains="Mac_PowerPC)" />          <browser nm="Gecko" minversion="1" />          <browser contains="FireFox" />       </excludes>    </functionality>    <functionality nm="Positioning" desc="Dynamic Positioning of Elements">       <supports>          <browser nm="IE" minversion="4" />          <browser nm="Netscape" minversion="5" />          <browser nm="Opera" minversion="7" />          <browser nm="Gecko" minversion="1" />          <browser contains="Konqueror" />          <browser contains="Safari" />          <browser contains="FireFox" />       </supports>       <excludes>       </excludes>    </functionality>    <functionality nm=" SingleCharDelimiters" desc=" Supports single character  delimiters (i.e. Char(18))">       <supports>           <browser nm="*" />       </supports>       <excludes>          <browser contains=" Mac_PowerPC)" />       </excludes>    </functionality> </capabilities> 

As you can see, each functionality group enables you to clearly define which browsers are supported and excluded for each separate test. In the test shown in Listing 10-1, the functionality being tested for is whether the client browser supports DHTML. Based on the ClientAPICaps.config file, you can see that if he user is browsing a web site using Client API with Internet Explorer version 4 or above, the user's browser is supported, and a value of true is returned.

After a functionality test is done, the next step is to register something on the client's browser. This can be a namespace for use on the client side as shown in Listing 10-1, or a variable or script block. When calling the RegisterClientReference function, you have to send it the Page object along with the ClientNamespaceReferences enumerator telling the function what namespace you are attempting to register. Each namespace is stored in a separate JavaScript file stored within the same folder as the ClientAPICaps.config file. When the RegisterClientReference function runs, it adds the corresponding file to the page so it can be downloaded by the client browser.