There is a couple reasons I have not been as active in posting to my blog as of late. First, I have been spending nearly none of my "home free-time" on coding. Instead, it has been focused on one of the few passions I have that is greater than coding, fishing. Every summer since I was young my family would take a 2 week trip to northern Wisconsin to a cabin my grandparents owned in Minocqua. Recently, my family has been getting involved in a few bass tournaments. This past weekend, we decided to try the Fishers of Men tournament in a chain of lakes in Madison. I must say that the tournament was very well run and we all had a blast. Of course this was helped by the fact that I caught my biggest Wisconsin bass ever on tournament day (5.37 lbs.). This catch won the big-bass of the tournament along with helping us to a 1st place finish. We are fishing one more on the same lakes in two weeks and hoping for similar results :)
Due to this lack of time I decided to cheat a little on this blog entry update. I will simply introduce a conversation we had on the core team and copy and past the relevant parts from that discussion.
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.
As usual, the actual coding for the client-side reordering was not the difficult part. I hacked out a first cut in with little trouble at all. Where I am running into issues is in deciding how to abstract it. Let me explain...
I have a new server-side method that allows a user to register a particular button to take place in the re-ordering of the rows in the table
Public Shared Sub EnableClientSideReorder(ByVal objButton As Control, ByVal objPage As Page, ByVal blnUp As Boolean, ByVal strKey As String)
objButton - button that will cause the client-side reordering
objPage - page object being displayed. Can't use objButton.page cause when the grid renders the button it is not attached to the page yet.
blnUp - Determines if it is an up or down button
strKey - key used to retrieve the new order. Probably best to use something like grd.ClientID
When a postback occurs you use this method to obtain the new order
Public Shared Function GetClientSideReorder(ByVal strKey As String, ByVal objPage As Page) As String()
strKey - key used in the registration
objPage - page object
This will return an array of numbers containing the new order. For example if the user did not re-order anything the array would look like
0,1,2,3,4,5
If the user moved the first row down two spaces it would return
1,2,0,3,4,5
As you can see this is a very generic implementation. The only assumptions made are that the buttons are contained within a Table and that the user will register a button on each row in the table in a continuous manner. i.e. the table can have its first couple rows not take part in the reordering and the last couple rows. But they won't have the first 3 take part and not the fourth and then register the 5th and 6th.
Ok, now on to the question of where to put this. Things like expand/collapse and drag-n-drop are considered DNN specific because their implementations make a lot of DNN specific assumptions. Therefore their server-side code is contained in the DNNClientAPI class and the client-script is contained within the dnncore.js file. My initial cut at this assumed that the code for the table reorder would be placed in those two files. However, as I've stated there is nothing DNN specific about this code, not to mention that the dnncore.js file is getting large.
I could place the code in the ClientAPI.vb file and one of the generic script files, but I am not sure that I have one that fits. The closest thing I have is the dnn.dom namespace that provides methods for manipulating the dom. These methods perform dom manipulation, but in addition they make certain assumptions about what rows can be swapped based off of registered keys. This doesn't seem to fit...
So, I am considering doing is coming up with the concept of a utility namespace for the clientapi, so that anyone can create a new utility script that will only be loaded when used. In this case dnn.util.tablereorder.js. If I go this route I eventually may break out the drag-n-drop logic in the dnncore.js as well...
I ended up choosing the separate util namespace (dnn.util.tablereorder.js). As you have read, this functionality will be available to anyone who wishes to incorperate a cross-browser client-side method of reordering a table through the use of two simple methods. To see this functionality in action you can look at the Manage Profile Properties screen when DNN 3.3 releases unless of course, you are a Platinum Benefactor and can see it now.