With DMX 5.3 there has been a significant overhaul of the UI, but not one of the kind that you quickly notice it. This seems contradictory, but allow me to explain. For years now Document Exchange is the most powerful document management tool for DotNetNuke. In IT there is a rule that is hard to get away from: more power = slower. That is to say: the more powerful your architecture is, the more processing it will require and hence the slower it will run. This means that for DMX there is always a healthy interest in tweaks to improve performance. The new Ajax UI that was introduced in DNN 4 allows for a near Windows like experience through the web page. There are a bunch of components that constantly talk to the server and refresh. There are benefits and disadvantages to this regarding performance. The benefit is that the page does not need to reload so the skin context is retrieved just once. But the disadvantage is that there are frequent calls to the server. In DMX many things are cached to speed up processing, but there is a good reason to try to suppress calls to the server where possible.
Using sprites is one big step forward here. CSS sprites allow the client to download one image file and create the rendered page by cutting out small blocks from that large file. This means that the client no longer needs to retrieve a bunch of images one image at a time but that it does it in one go. As explained in an earlier post this has reduced the calls to the server by 50% for this module. The underlying reason is the intense use of icons throughout the module. Icons greatly improve the user experience, but if the client needs to get 50 icons one at a time, you get a lot of server calls.
Moving forward this is really a technology to leverage in DMX. Although the manufacturer of the controls we use (ComponentArt) do not officially support sprites, I have seen enough of their code to know they, too, are mving in this direction. The difficulty implementing this in DMX was in the fact that some of these components were built such that “old style CSS” could not properly set the icons in place. This meant that on legacy skins (non XHTML compliant) Internet Explorer would not show the icons in the treeview or on the menu.
In an effort to support legacy skins jQuery was used to dynamically set the icon class on the right element. Only: DNN 4 does not load jQuery (and only from version 4.9.2 was jQuery even added to the DNN release). So a new workaround was necessary (now in 5.3.1) to make sure jQuery loads and the script is able to set the icons right.
The above is not exceptional. This kind of puzzling is more and more the bread and butter of our daily work. Why more and more? Well, since the DNN Corp capital injection we’ve seen a murderous pace of releases of DNN with new features in each. In order to leverage these features we need to find a method to “catch any errors if the platform is too old”. I’m not saying the new features are a burden to our work, just that we often can’t use them as quickly as we want or we need to find a solution to support the older frameworks.
With 5.3.1 there is a new release a week after the 5.3.0 release. Several fixes concern the combination DNN 4/legacy skin/IE only. I hope you enjoy this release.
Release notes: http://www.bring2mind.net/Support/Forums/tabid/143/forumid/26/view/topics/Default.aspx