Navin Pathuru asks:
Currently we have a requirement where our client wants us to do something about loading Dnn in Netscape 4.x version. We know Dnn uses a lot of client side javascript so there are going to be problems with this. But we just
want to do our best. The approach we want to take is to figure out the browser version and load a different
skin one which has really minimal graphics when we detect it is Netscape 4.x. I am wondering if you will
be able to write your thoughts about this approach in your blog.
Nik’s response:
Navin, this is a great question. Before I answer it, I do want to point out that most of the client-side Javascript you see on a DNN page is emitted by ASP.Net, the menu and other modules. DNN itself does not generate a lot of client-side script, especially if you disable the Client API.
Now, to answer your question. Since we have the DNN source code, the dime answer is change the core to suit your needs. But this is neither fun nor practical. Let’s go on to the dollar answer.
DNN uses the tab settings (inherited or set directly) to determine which skin is to be displayed. You can override this with querystring parameters to force a certain skin to be displayed. Also, due to its IBuySpy legacy, DNN has the rather unfortunate artifact called the Admin skin which forces a skin switcheroo whenever a non-View module control is displayed. (I think this will go away as part of DNN’s continued evolution.)
So, if there is no way to dynamically switch the skin, how is this problem to be solved. After noodling about this for a minute, it occurred to me. Although DNN allows skins to be intelligent, most skins are dumb, i.e. they intersperse some DNN controls, HTML, images and CSS to render a page layout. Most skins do not take advantage of their ability to do anything ASP.Net allows by virtue of their being usercontrols. This is precisely what we can do to solve the problem at hand.
The solution consists of a single file that I’ll call a “Skin Proxy.” The Skin Proxy can be used to dynamically select a skin based upon any user, portal, tab or browser properties. In my example, I have used a browser property since that was the focus of Navin’s question. Basically, the Skin Proxy creates a string based on some browser properties and then attempts to load a control (i.e. a skin) with a name matching the string.
SkinProxy.ascx
<%@ Control language="c#" %>
<script runat="server">
protected void Page_Load(object s, EventArgs e)
{
string browser = Request.Browser.Browser.ToLower();
string version = Request.Browser.MajorVersion.ToString();
if (Request.QueryString["debug"] != null)
Response.Write(browser + version + ".ascx");
else
{
try
{
this.Controls.Add(this.LoadControl(browser + version + ".ascx"));
}
catch
{
this.Controls.Add(this.LoadControl("Default.ascx"));
}
}
}
</script>
In this code, the first couple of lines get the browser and browser major version into string variables. Then, an attempt is made to load a control whose name corresponds to the concatenated browser and version. If this is unsuccessful, a control named “Default.ascx” is loaded. (If you add a querystring variable named “debug” the script reports the name of the control that would be loaded instead of actually loading it. This is helpful for figuring out what to name your control.)
I tested this out with IE and Firefox and everything seemed to work OK. Please do post here if you find problems with the script.