Posted by: Jon Henning
6/15/2007 

I have finished the initial conversion of the DotNetNuke WebUtility (ClientAPI) project to utilize the Microsoft ASP.NET AJAX Extension framework.  This has several advantages and one major disadvantage.  The disadvantage is that upgrading to it will require Microsoft ASP.NET AJAX extensions (System.Web.Extensions.dll) to be installed.  I do not have the time, nor do I think it worth the effort, to provide an optional install.  Technically, since the current implementation does not require the extensions and the new one does, I do have an optional install.  So I guess all this means is that if any enhancements or bugs are going to be added, only the code supporting the extensions will be upgraded (unless it is considered a major fix).  There has been no timeline set as of the writing of this blog as to when this will be integrated into the core.  Obviously, it cannot be integrated until we can make the same constraint of requiring the extensions to exist. 

When I first heard about Atlas (Microsoft ASP.NET AJAX Extensions) I had an idea on how the ClientAPI and Atlas were going to fit together.  I had envisioned the ClientAPI to simply be an extension to Atlas.  The areas where the logic overlapped I would simply delegate the task to Atlas, and there would be no break in compatibility.  Examples of this include the ClientAPI’s createDelegate, getCurrentStyle, and getById methods.

createDelegate: function(oThis, pFunc)

{

  return Function.createDelegate(oThis, pFunc);

  //return function() {pFunc.apply(oThis, arguments);};

},

getById: function(sID, oCtl)

{

    return $get(sID, oCtl);

       /*if (oCtl == null)

              oCtl = document;

       if (oCtl.getElementById)

              return oCtl.getElementById(sID);

       else if (oCtl.all)

              return oCtl.all(sID);

       else

              return null;*/

},

getCurrentStyle: function(oNode, prop)

{

       var oStyle = Sys.UI.DomElement._getCurrentStyle(oNode);

       return oStyle[prop];

       /*

       if (document.defaultView)

       {

              if (oNode.nodeType != oNode.ELEMENT_NODE) return null;

              return document.defaultView.getComputedStyle(oNode,'').getPropertyValue(prop.split('-').join(''));

       }

       if (oNode.currentStyle)

              return oNode.currentStyle[prop.split('-').join('')];

       if (oNode.style)

              return oNode.style.getAttribute(prop.split('-').join(''));  // We need to get rid of slashes

       return null;

       */

},

Where the ClientAPI logic is commented out and the delegating of the task is using Atlas.  As I began to do my conversion I ran into quite a few scenarios where if I did this delegation, I would lose functionality.  For example, my client-side browser detection logic handles Internet Explorer, MacIE, Netscape, Mozilla (FireFox), Opera, Safari, and Konqueror.  Atlas on the other hand only detects Internet Explorer, FireFox, Safari, and Opera.  This is primarily due to the fact that it only supports these browsers.  There are quite a few routines in the ClientAPI that do different things on a per-browser basis (which is also true of Atlas).  If these routines delegated their work to Atlas, they would lose functionality.  This has led me to the decision of only delegating off work when no compatibility is lost and recommending to the community to only use the ClientAPI with these methods when you need to.  Otherwise, call the Atlas methods directly.

I am running short on time these days.  I plan on posting more information on this subject soon.  I also plan on releasing a Community Technology Preview (CTP) to a limited set of users to help me test out the new ClientAPI integration with the ASP.NET Extensions and hopefully iron out any bugs while we wait for broader adoption of the ASP.NET Extensions.  In the meantime, I figured some of you may be interested in the size differences between the original ClientAPI files, and the newly converted then compressed (like the control toolkit does) files.

Trackback Print

Tags:

Categories:

Location: Blogs Jon Henning Core :: ClientAPI