Posted by: Jon Henning
8/29/2005 

One of the advantages to having as long of a release cycle as I have had with the Client API is I can get a lot of fundamental framework changes implemented.  One of the disadvantages of a long release cycle is I have coded so many fundamental framework changes it is overwhelming to consider both integrating and testing, especially when it comes to the backwards compatibility the DNN community has come to expect.

Way back in march 2005 I had introduced to the core the updates to the ClientAPI that would allow for client callbacks, complete with an eleven page document.  This was a goal of the CAPI since its inception.  Having done many apps in the past utilizing callbacks in the late 90s I realized the power it could provide, especially when exposed in a cross-browser fashion.  The vision for this funcitonality extended beyond having module developers utilizing its functionality.  It would encompass the entire navigation scheme within DNN, in a similar fashion to what ASP.NET 2.0 will provide.  Only my implementation's goal was to work in more browsers and be utilized by many controls, including ones for .NET Framework 1.x. 

The short term goal was to give the DNNTree control a complete overhaul and remove as much viewstate as possible.  Additionally the payload it sent down was analyzed and a design was laid out to strive towards efficiency.  Part of this smaller payload would be accomplished through the use of Populate On Demand (POD) functionality.  I had hoped that this portion of work would make one of the stabilazation builds shortly after 3.0 was released.  However, due to the long release schedule leading up to 3.0 the core team decided to concentrate on a
much more focused set of deliverables and the enhancement got shelved.

A little dissappointed, I decided to use the time to further the development of my vision for the ClientAPI.  This included giving the DotNetNuke community additional controls, including the DNNMenu and DNNTextSuggest.  A few people asked me, the author of the Solution Partners Hierarchical Menu Control, why I would develop a competing menu control to my own.  The answer is simple.  The SolpartMenu is old and carries a lot of baggage with its almost 4 years worth of backwards compatibility.  It has been a goal for v2 of the solpartmenu to abstract all of the common logic not specific to the menu into separate js files that could be reused by other controls and applications.  This is exactly what the ClientAPI is; an abstraction of logic like positioning, DOM access, XML, etc.  The script for the menu should contain only code for the menu, thus making it easier to maintain and enhance.  So in essense, the DNNMenu is in a lot of ways the solpartmenu v2.0. 

Trackback Print

Tags:

Categories:

Location: Blogs Jon Henning Core :: ClientAPI