Core :: ClientAPI

Minor Perf Optimization to Caspian Release

jon.henning@dotnetnuke.com — Mon, 14 Apr 2008 06:00:00 GMT

While sitting at the airport waiting for my plane to depart to the MVP Summit, I decided to spend a little time optimizing the new ClientAPI (codenamed Caspian) for the Cambrian release. One of the new features for this release was to allow the output of the ClientAPI and Webcontrols to emit compliant markup (more detail mentioned in this blog). There was two areas that this affected my code.

Javascript Global Namespaces (the dreaded $ function)

jon.henning@dotnetnuke.com — Mon, 24 Mar 2008 08:00:00 GMT

The whole idea of the $ function and who "owns" that "namespace" has become quite muddy. When I first learned of the use of $ and found that MS was adopting the same notation, I decided to do it as well. For at the time, I felt that all frameworks simply used it as a quick way to get the reference to a DOM element. Soon afterwards I learned that frameworks like prototyle use it for much more.

We Be 'Tweening

jon.henning@dotnetnuke.com — Fri, 05 Oct 2007 18:05:32 GMT

Ever since version 1.0 of the Solpart menu, it supported animations. Unfortunately, these animations were specific to IE due to it being the only browser that supported transitions natively. When I created the DNNMenu I had decided not to go this route, but rather seek out a technique that worked across all browsers. When I was first reviewing the Atlas bits, there was a portion called Glitz, which I had anticipated would support the animations I was looking for. Unfortunately, Glitz never became an official part of the framework. This caused me to research how animations are written that look smooth. I stumbled upon the concept of Tweens, which eventually led me to Robert Penner's free tweening chapter. In reviewing it I had decided to try my hand at implementing something similar inside the ClientAPI. This led to the creation of the dnn.motion namespace. To demonstrate its functionality have a look at the new webcontrols site.

Notice how the icons in the header of the page gracefully fall and bounce into position. This effect is possible thanks to the mathematical formula specified by Mr. Penner. All a developer has to do to implement it is first register the motion namespace from the server

If ClientAPI.BrowserSupportsFunctionality(ClientAPI.ClientFunctionality.Motion) Then
  ClientAPI.RegisterClientReference(Page, ClientAPI.ClientNamespaceReferences.dnn_motion)
End If

Then on the client simply tell the animations how to behave with the following code

dnn.dom.doTween(id, ctl, 'top', dnn.easing.easeOutBounce, -100, 50, 1);

Parameter	Description
id	ID to uniquely identify animation. Useful if you wish to stop or replay the animation
ctl	Control to animate
property	Property to modify for animation Valid values are any style name (top, height, etc.) plus cliptop, clipbottom, clipleft, clipright
easeFunc	Easing equation to use (linearTween, ease[In/Out/InOut]Quad, ease[In/Out/InOut]Cubic, ease[In/Out/InOut]Quart, ease[In/Out/InOut]Quint, ease[In/Out/InOut]Sine, ease[In/Out/InOut]Expo, ease[In/Out/InOut]Circ, ease[In/Out/InOut]Bounce) - if these seem overwhelming, read the chapter.
begin	starting value for the property (in our sample we start at top=-100
finish	finishing value for the property (stop at top=50)
duration	number of seconds to run the tween
interval	(optional) how often animation gets updated (milliseconds). The lower the number the more smooth but also the more demanding on the CPU (default=10)
suffix	(optional) suffix to append to value (px for example)
onStartFunc	(optional) function to invoke prior to animation
onFinishFunc	(optional) function to invoke after animation

Another example of the use of animations can be found in the animations sample page. This sample utilizes the same doTween implementation for the mouse over and out events. However, when the icon is clicked, it uses a "canned" animation technique to give the appearance of the box sliding out underneath the icon. This effect is done by combining multiple tweens together. To invoke these techniques the element being animated must have its positioning specified as absolute.

dnn.dom.animate(m_Description, dnn.motion.animationType.Slide, 'right', 1, 1, 
	dnn.motion.easingType.Expo, dnn.motion.easingDir.easeInOut);

Parameter	Description
ctl	Control to animate
type	[dnn.motion.animationType enumerator] Ttype of animation (Slide, Expand, Diagonal, ReverseDiagonal)
dir	[dnn.motion.animationDir enumerator] direction (up, down, left, right)
easingType	[dnn.motion.easingType enumerator] Type of equation to use (Bounce, Circ, Cubic, Expo, Quad, Quint, Quart, Sine)
easingDir	[dnn.motion.easingDir enumerator] Direction of animation (easeIn, easeOut, easeInOut)
duration	number of seconds to run the animation
interval	(optional) how often animation gets updated (milliseconds). The lower the number the more smooth but also the more demanding on the CPU (default=10)
onStartFunc	(optional) function to invoke prior to animation
onFinishFunc	(optional) function to invoke after animation

The animate function is utilized by the new DNNMenu and eventually other webcontrols. The menu on the WebControls sample site currently uses the Slide technique to show and hide the sub-menus. To apply custom settings when using the control directly, the following markup is used.

You can play with the different settings allowed for the menu animations on this sample page.

In case you are wondering how animations can be applied to the navigation controls within DNN, the current plan is for the Nav skin object to allow access to the these properties through the CustomAttributes collection.

<CustomAttributes>
  <dnn:CustomAttribute Name="AnimationType" Value="Slide"/>
  <dnn:CustomAttribute Name="EasingType"Value="Bounce"/>
  <dnn:CustomAttribute Name="EasingDirection"Value="Out"/>
  <dnn:CustomAttribute Name="AnimationLength"Value="1"/>
  <dnn:CustomAttribute Name="AnimationInterval"Value="10"/>
  <dnn:CustomAttribute Name="RenderMode"Value="Normal"/>
CustomAttributes>

That's enough information for this blog. I will be covering this topic briefly, along with a whole lot more of the new features available to the module developer in my session at OpenForce '07..

Animation-AnimationType="Slide" Animation-EasingDirection="Out" Animation-EasingType="Expo"

Tradeoffs In Script Registration

jon.henning@dotnetnuke.com — Fri, 15 Jun 2007 12:55:56 GMT

One interesting enhancement that the AJAX Control Toolkit team came up with in the latest release is yet another way to register your scripts (ToolkitScriptCombiner). Earlier I blogged on the fact that Microsoft can’t seem to make up its mind on how these things should be registered. In the Control Toolkit team’s case, it is not bad, as they are inheriting from the ScriptManager, and extending its functionality, so as long as Microsoft keeps with the ScriptManager for script registration, their method should work. So what did they do, you ask? Well, they decided to tackle an issue I have debated for a long time. How much should you include in your script? Should it contain everything and affect the initial load time of a page, or should the script be small chunks of code only containing what is necessary to allow the page to function? As with most programming techniques, there is always tradeoffs. In the case where you include everything (as the MicrosoftAjax.js file does) you pay a big price (relatively speaking) the first time a visitor hits your page. However, after the initial load, the only price you pay is a small request checking to see if the script has been modified. In the later case, where you have many small scripts, the initial load only grabs the script necessary, thus making the initial payload smaller. However, every load thereafter, needs to make a request verifying the script has not been changed. So if you broke your functionality into 10 scripts, each page requested results in no less than 11 requests (1 for the page, and 10 for each js file). Note: the same holds true for css and image tags.

So what is the correct answer? What I came up with for the ClientAPI is a compromise between the two. The ClientAPI groups its scripts by functionality (dnn (common functionality), positioning, xml, xmlhttp, diagnostics, and scripts). What the Control Toolkit came up with is a new control that will aggregate all scripts for a given page and send down a single script reference. I am not sure what I think of this idea at the moment. Let me explain my reservations with an example. Lets say you have 3 scripts A, B, and C. Lets also say you have 7 pages with the following script references.

· Page1 (A)

· Page2 (B)

· Page3 (C)

· Page4 (A,B)

· Page5 (B,C)

· Page6 (A,B,C)

· Page7 (A,C)

As noted above, the initial page load is the most costly, since it needs to download the scripts content. In the scenario above (made a little extreme to demonstrate my point), you would have 7 initial script loads. Whereas, if you kept the 3 scripts separate, you would have only 3 initial page loads. After the initial load you would only have one, which is as good as having a single file, but I’m not sure that the cost of the 7 initial loads outweighs the cost of having a single large load. I guess it is up to the page developer to determine where he or she places their emphasis.

Now is also probably a good time to briefly talk about resource files, as they are coming soon to the ClientAPI. Embedding your resource files in a dll has one main advantage. It guarantees your server-side code is in sync with your client side code, thus easing the distribution and maintenance of your codebase. The disadvantage of course, is that resource files are processed by the ASP.NET process, thus increasing the workload of your webserver (however small). I believe that the Control Toolkit team has a switch allowing the use of resource files or not, but I am assuming that if you don’t use them you don’t get the script aggregation functionality. Similarly, the ClientAPI will allow the toggling of the use of resource files via the ClientAPICaps.config file.

supports>

excludes>

functionality>

If using an embedded resource, how the dll is compiled will determine what version of the scripts will be sent down (compressed for Release, developer for Debug). The MSBuild file for the ClientAPI will also generate both sets of external js files, by default placing the debug versions of the script files in a subfolder.

The ClientAPI Integrates ASP.NET AJAX Extensions

jon.henning@dotnetnuke.com — Fri, 15 Jun 2007 12:49:16 GMT

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.

Script Name	Original Size (bytes)	Compressed Size (bytes)	Percent
dnn.js	29,261	19,856	32%
dnn.dom.positioning.js	11,433	8,439	26%
dnn.xml.js	7,810	4,857	38%
dnn.xml.jsparser.js	7,204	4,909	32%
dnn.xmlhttp.js	6,429	4,015	38%
dnn.xmlhttp.jsxmlhttprequest.js	2,555	2,102	18%
dnn.scripts.js	1,658	1,243	25%
dnn.util.tablereorder.js	3,757	3,047	19%
dnn.diagnostics.js	5,729	4,064	29%

Compatibility Between Javascript Frameworks

jon.henning@dotnetnuke.com — Sat, 14 Apr 2007 02:00:00 GMT

I will be releasing the next point release of DotNetNuke WebControls (v1.5.3) shortly. There are a couple reasons for this. First, it was detected by some users that the currently released version with DNN 4.5 was compiled in Debug mode, thus affecting performance a little. The second, and primary reason is due to our desire to try (emphasis on this word) and maintain compatibility with other AJAX frameworks. In this case we are talking about prototype.

To explain the compatibility issue, it may help to think of what the new LINQ functionality offers and how it works. It utilizes a new technique called Extension Methods. This allows for new methods to be attached to any object (In LINQ's case it is IEnumerable). LINQ will only attach these methods if the namespace is imported. Javascript is pretty much the same. Inside javascript there are a few native objects (string, number, array, date). Some js frameworks like prototype decide to add their own custom methods to these objects (when imported or referenced). This starts to cause compatibility problems when new methods get added to these underlying objects. The specific case here has to do with the Array object. In some of my code I use an array without indexes (like a hashtable). Lets say we have the following array defined.

var myarray = new Array();

myarray['bob'] = 1;

myarray['joe'] = 2;

To enumerate it I use the following script

for (var sKey in myarray)

The only values obtained from the array and placed in the sKey variable should be bob and joe. However, if the Array object was extended, this will unfortunately contain the newly added functions. To get around this a check was inserted into some of the js scripts

if( typeof sKey is "function" )

continue;

While extension methods are very powerful, it is one of those things that should be used with care. Especially if a user anticipates multiple frameworks co-existing.

This fixes the current issue, but I think it is worth discussing a much larger issue. The ClientAPI has taken care to expose a minimal surface area it can affect. For the most part the only thing it "owns" is the dnn and dnncore namespaces (and everything under it). The one exception to this is the $ function (which I regret, see here). Other frameworks have taken a much more liberal approach to what they try to "own". Its one thing for my framework to have to trap for this enumarator's case, but what happens if I want to extend Array as well, and what happens if I choose a function name that conflicts with one or more frameworks and is a little different in its implementation that the others?

The answer, is random chaos. Whichever framework's js is registered last will "win".

Client-Side Personalization - A Sneak Peek At 4.5.0

jon.henning@dotnetnuke.com — Fri, 02 Mar 2007 15:10:00 GMT

Being able to retrieve and set personalization values on the client is a new feature that DNN will support for version 4.5. Since personalization is something specific to DNN, the code will reside in the DNN specific ClientAPI files of dnncore.js and DNNClientAPI (ClientAPI.vb). The current state of the dnncore.js is such that it does not utilize namespaces. Instead it prefixes all function names with __dnn_. Module developers use these client-side functions when they are calling server-side methods like AddBodyOnloadEventHandler and EnableMinMax, but they are not intended to be used directly from the client. Since we now wish to expose client-side methods for setting and obtaining personalization values, the creation on a new namespace is in order.
The name of this namespace will be dnncore. To start out, it will only support personalization methods, but eventually the entire set of dnncore functions will be encapsulated.

Since the core is in the process of adapting the MS AJAX framework, I have decided to start following some of their naming standards, specifially, denoting a method is meant to be private by the prefixing of an _ (underscore).

The first two methods of dnncore that are not private are

dnncore.getUserProp(sNameCtr, sKey, pFunc)
dnncore.setUserProp(sNameCtr, sKey, sVal, pFunc)

sNameCtr - The concept of the naming container serves a similar function to namespaces in our js and .NET code. It enables our keys to be unique between our modules.
sKey - The key parameter should also be self explanitory. It is the property name we are setting or retrieving.
sVal - The setUserProp obviously needs to pass a value to assign.
pFunc - pointer to function to invoke with results from our async callback.

Pesonalization has existed in the DNN Framework for a long time. Therefore, most of these parameters should be easy to understand. The one exception to this is the pFunc parameter. To explain this it is important to remember is what the first A in AJAX stands for. Thats right, Asynchronous! Javascript is a single threaded environment. There is no way to do some sort of looping structure with something like DoEvents (VB) while we wait for a result. Some of you are probably saying that the XMLHTTP object that the MS and Mozilla/FireFox offer has a property that allows for async to be true or false. Additionally, the method the ClientAPI exposes has a parameter for async. What gives?
Causing javascript to execute a synchronous request to the serer is not a good idea, for it will make the browser appear to be locked up. Additonally, support for browsers that do not have their own XMLHTTP object would be impossible. Most AJAX frameworks utilize the hidden IFrame method to utilize postbacks for these browsers. As you know, the requesting of a webpage is certainly not synchronous.

So how do you obtain a value?

Code similar to this can be used.

function getUserSettings()
{
dnncore.getUserProp('MyModule', 'backgroundColor', setValue);
dnncore.getUserProp('MyModule', 'color', setValue);
}

function setValue(sNameCtr, sKey, sVal)
{
$('mytextbox').style[sKey] = sVal;
}

function setUserSettings()
{
dnncore.setUserProp('MyModule', 'backgroundColor', 'yellow');
dnncore.setUserProp('MyModule', 'color', 'blue');
}

Some of you may be asking, since this is just javascript, how can I be sure that users don't obtain any personalization value they want? Or, how can I stop them from putting a bunch of junk in these tables, thus bloating my database?

Both of these are legitimate concerns. The first, however, depends on what module developers are storing in the user's personalization. Most likely, these are simple settings the user already knows about. The second, is a bigger concern, and therefore something needs to be done to limit what values can be inserted. To address both concerns, the DNNClientAPI class now has a method that needs to be used to enable a personalization property to be both set and retrieved.

EnableClientPersonalization(ByVal strNamingContainer As String, ByVal strKey As String, ByVal objPage As Page) As Boolean

strNamingContainer - personalization naming container
strKey - personalization key
objPage - page being rendered (handles callback)
ReturnValue - Returns True when browser supports client-side personalization. If this returns false, it is your responsibility to ensure that your code still functions, most likely with postbacks.

The core has supported the EnableMinMax method for a long time now. One of the parameters going into this method is PersonaliztionType. The supported types consisted of: None, Page, and Cookie. A new type has been added to support persisting to Personalization. Support for this requires an additional overloads to be added to allow the developer to pass in the NamingContainer and Key for personalization.

In addition to module developers having another cool tool in their toolbox, the core has also utilized this feature. The newly updated control panel currently has min/max capability, that persists between page requests. This is now persisting with the new overloaded EnableMinMax.

DotNetNuke.UI.Utilities.DNNClientAPI.EnableMinMax(imgVisibility, rowControlPanel, Not IsVisible, Common.Globals.ApplicationPath & "/images/min.gif", _
Common.Globals.ApplicationPath & "/images/max.gif", DNNClientAPI.MinMaxPersistanceType.Personalization, "Usability", "ControlPanelVisible" & Me.PortalSettings.PortalId.ToString)

Adventures In Script Registration

jon.henning@dotnetnuke.com — Thu, 04 Jan 2007 04:00:00 GMT

Before I get into the reason for the article I wanted to wish everyone a Happy New Year! I have been very busy the past couple months on the next version of the ClientAPI and WebControls and am getting anxious about publishing my work. However, I am going to need a couple weeks to gather my work up again after the long holiday and polish it off a bit. In the meantime I wanted to give a quick bit of history regarding my decision in how to obtain what scripts need to be registered during a partial rendering event.

In version 1.0 of the framework we were blessed (sarcasm) with the use of a HybridDictionary to hold our page's registered scripts. This had the unfortunate side-effect that after 9 scripts were registered the order they were emitted to the browser was random. (If you ever looked at the ClientAPI’s js files you will see a lot of extra work at the end of each file that is necessary to work around this issue.)

In .NET 2.0 Microsoft finally removed the HybridDictionary, and decided to do away with the normal way of registering scripts (on the Page object) and introduced a new object, the ClientScriptManager. The unfortunate thing about the newly redesigned object is they offered no way to obtain a list of scripts that are registered. Initially, the Atlas team at Microsoft decided to work around this issue for their UpdatePanel by writing "extremely hacky parsing work". At the time I found writing a routine to parse the page output looking for script tags hacky as well (and I still do).

Apparently the Atlas team could not convince the Framework team to make the script collection accessible in the upcoming SP1 (pure speculation on my part), so they decided to invent yet another object used to render client scripts (ScriptManager). This allowed them to do away with their hacky parsing logic. I am beginning to think this whole adventure in script registration is looking similar to my adventures in data access objects over the past decade (DAO, RDO, ADO, ADO.NET, etc...)

Personally, I feel that it would have been much better for SP1 to simply expose the script collection in a readonly manner (if necessary). However, I am sure there are some good reasons they have not done so. Requiring control vendors to change their code to detect the presence of certain objects via reflection in order to figure out which register script method to call is a major hack IMO.

So what does this have to do with the ClientAPI? Well, in dealing with partial rendering for the DNNTabStrip I need to determine if a partially rendered tab needs to send down new script. While I could have gone the Atlas route and came up with my own script object that other control vendors would need to detect and use if present, I am not naive enough to think that I could pull that off. Microsoft may have the backing to pull something like this off, but I know I don't. I could have tied into the Atlas script manager, but at this point I do not want to marry my library with theirs. Perhaps in a couple months I may consider it, after the widespread adoption of SP1. However, you need to remember that I am still supporting .NET 1.x at the time of the writing. Another option would be to hack into the script collection via reflection. In case you are unaware, you can access private variables in your code using reflection. This, however, is not advisable, as Microsoft may change the underlying objects names at any time without breaking compatibility.

So the only option left to me was to write my own "hacky script parser". Being that I am new to regular expressions I feel this may prove to be a weakness in my implementation. However, I do have confidence that given some help, I will be able to work through these issues. My current expression to parse arbitrary html looks as follows.

(?i:
(?:<
  (?[^/ >]+)
  (?:\s(?!/)+
  (?:
   (?[^=]+)
   =(?:"|')
   (?[^"\']+)
   (?:"|')
  ))*
  )
(?:
  [^/]*/>
  |
  [^/]{0}>
   (?[^<]*)
  (?>+)
)
)

If you are one of the fortunate programmers out there blessed with the ability to read these expressions easily, please have a look and let me know if I can improve it.

Open-Source Javascript Editor

jon.henning@dotnetnuke.com — Mon, 18 Sep 2006 20:30:00 GMT

Back in 2004 when I was creating the ClientAPI I spent some time trying to find the best way to edit javascript, with hopes that I would find a solution that offered IntelliSense™ and an easy means to document it. Having found neither I decided to create my own console app to transform an XML file into documentation. While this is a starting point, it sure is a far-cry from the in-line IntelliSense™ documentation we as developers have become accustomed to.

A couple days ago I was reading one of the blogs I subscribe to that discussed javascript editors. The first response to that blog was for an open-source project called Aptana. I decided to download it, in hopes that it would provide me a much better javascript editing experience than what is currently offered by Visual Studio.

I must admit that my first impression was one of confusion, for the product uses different terminology than I am accustomed to (namely perspectives). However, seeing that my main goal was to get IntelliSense™ (they call it Code Assist) to work, I decided to simply focus on what was necessary to accomplish this. It proved to be quite easy. Simply drag the js files you wish to take part in Code Assist to the Code Assist Profiles window and your editor now offers fairly accurate IntelliSense™ for the entire ClientAPI.

This editor seems to offer other features I am quite interested in, namely the ability to document the api, have it show up in Code Assist and provide some sort of HTML documentation. I assume there is a way to strip out the documentation comments as well, along with being able to reliably compress the javascript. I wish I had more time to tinker with this, but there is way too many other things I need to get done first. If anyone has some free cycles to play with these features, don’t hesitate to send me an email with some of your findings.

Client Side Reordering

jon.henning@dotnetnuke.com — Wed, 24 May 2006 12:00:00 GMT

A couple months back the core team was going over some of the excellent enhancements Charles was working on for the 3.3/4.1 release. One of those pages offered the ability to customize the user properties, including the order in which they were displayed. The traditional method for reordering a list was implemented, meaning the use of postbacks. I was tasked with coming up with a better way to accomplish this without requiring postbacks.