WebParts and jQuery
So, after quite a bit of fiddling with code, I’ve managed to implement the code that lets me use jQuery to move WebParts around.
There were two different hurdles I had to overcome to get this done. The first was a weird behavior I found with MasterPages within my project, and the second was the fact that I didn’t know where this code was supposed to come back to on the server.
I don’t know if this has ever happened to you, but part of the beauty of MasterPages is that you can define things at different levels depending on when things are going to change. If there’s a heading or a menu that will be on all your pages, but if it’s only on a specific page, then you don’t have to put it on the top level. It’s great for organizing.
And if I did it in the MasterPage, then any of the lines I put in the Page’s Header didn’t show up. It was really frustrating.
Eventually, I copied what I had going in a different page–using
Page.Header.AddScript(/* script here */, false);
and that seemed to work just fine. As always order is important (especially when dealing with jQuery, as it has to be loaded first before you can call any of it’s functions).
jQuery WebParts on the Move
The last problem I had to deal with is intercepting the WebPart drop message. I could see that the code was firing a PostBack event back to the server, but I could not find where that event should have been handled. It’s then that I stumbled upon this tutorial on Understanding the __doPostBack Function. How did that help, well I was then able to use a couple of functions to find and intercept the source of the PostBack and move the WebPart accordingly.
Simply get the arguments, parse them out, and then move the WebPart to whatever WebPartZone and index that’s specified.
Now, I just have to figure out whether they look right, how the performance is from the database with actual charts, and make sure the CSS is right and away I go!