Update: I've posted the source and binaries for this control on Github. Free to use and change. Please comment on it.This is the story of a control that shrinks the content sent from an
UpdatePanel to down as 2% without using compression algorithms. I am willing to share the code with whoever wants it and I only ask in return to tell me if and where it went wrong so I can find a solution. Even if you are not interested in the control, the article describes a little about the inner workings of the ASP.Net Ajax mechanism.
You know the
UpdatePanel, the control that updates its content asynchronously in ASP.Net, allowing you to easily transform a normal postback based application in a fully fledged Ajax app. Well, the only problem with that control is that you have to either put a lot of them on the page in order to update only what changes (making the site be also fast as you would expect from an Ajax application) but hard to maintain afterwards, or put a big
UpdatePanel on the entire page (maybe in the
MasterPage) and allow for large chunks of data to be passed back and forth and also other clear disadvantages, some detailed in
this blog entry.
Not anymore! I have made a small class, in the form of a
Response.Filter, that caches the previously rendered content and instructs the browser to do the same, then sends only a small fraction of the data from the server to the browser, mainly what has changed. There is still the issue of the speed it takes the browser to render the content, which is the same no matter what I do, like when rendering a huge table. It doesn't matter that I send only the changes in one cell, the browser must still render the huge grid. Also, if, for some reason, the update fails, I catch it and I send to the server that the updatepanel must be updated again, the old way.
Enough; let's talk code. I first had to tap into the content that was sent to the browser. That can only be done at
Page render level (or
PageAdapter, or
Response.Filter and other things that can access the rendered content). So I did catch the rendered content in a filter, I recognized it as Ajax by
its distinctive format, and I only processed the
updatePanel type of token.
Here I had a few problems. First I replaced the
updatePanel token with a
scriptBlock token that changed the
innerHTML of the update panel
div element. It all seemed to work until I tested it a little. I discovered that the
_updatePanel javascript method of the
PageRequestManager object used by the normal ajax rendering on the browser was doing a few extra things, so I used that one instead of just replacing the
innerHTML, resulting in a lower speed. But that didn't help either, because it failed when using validators. Even if I did replace the
updatePanel token with a correct javascript block, it still got executed a bit later than it should have.
The only solution I had was to replace the
_updatePanel method with my own. Itself having a small block of code that disposed some scriptblocks and some other stuff, then a plain
innerHTML replace, I could not 'override' it, since it would change the
innerHTML with some meaningless stuff (the thing I would send from the server), then I would parse and change the
innerHTML again, resulting in bad performance, flickering, nonsense on screen, etc. So I just copy pasted the first part and added my own ApplyPatch function instead of the html replace code line.
Now, here I met another issue. The
innerHTML property of an html element is not a simple string. It gets parsed immediately when set and it recreates when read, as explained in
this previous article of mine. The only solution for that was create my own property of the update panel
div element that remembers the string that was set. This solved a lot more problems, because it meant I could identify the content to be replaced by simple position markers rather than through regular expressions (as was my initial idea). That property would not get changed by custom local javascript either, so I was safe to use it.
About the regular expression engine in Javascript: it has no Singleline option. That means you can only change the content line by line. I could have used
Steve Levithan's beautiful work, but with the solution found above, I would not need regular expressions at all.
The only other issue was with
UpdatePanels inside
UpdatePanels. I found out that in this case, only parent
UpdatePanels are being rendered. That meant that the custom property I added to the child panel would disappear and break my code. Therefore I had to keep a tree of the updatepanels in the page and clear all the children cached content when the parents were being updated. So I did that, too.
What else? What if somehow the property would get deleted, changed, or something else happened, like someone decided to recreate the update panel div object or something like that? For that I made a little
HttpHandler that would receive an
UpdatePanel id and it would clear its cached content. Then, on return from the asynchronous call, the javascript would just push another update panel refresh using
__doPostBack(updatePanelId,""). I don't particularily like this approach, since it could back fire with multiple
UpdatePanels (as you know, only one postback at a time is supported), but I didn't find a better solution yet. Besides, this event should normally not happen.
So, the mechanism was all in place, all I had to do was make the actual patching mechanism, the one that would find the difference between previously rendered content and current content, then send only the changed part. First thing I did was remove the start and end of the strings that were identical. As you can imagine, that's the most common scenario: a change in the UpdatePanel means all the content up to the change remains unchanged and the same goes for the content after the change. But I was testing the filter with a large grid that would randomly change one cell to a random string. That meant two changes: the previous position and the last. Assuming the first change was in one of the starting cells and the last was in one of the cells at the end, then the compression would be meaningless. So I've googled for an algorithm that would give me the difference between two files/strings and I found Diff! Well, I knew about it so I actually googled for Diff :) It was in the Longest Common Substring algorithm category.
Anyway, the algorithm was nice, clear, explained, with code, perfect for what I wanted and completely useless, since it needed an array of
m*
n to get what I needed. It was slow, a complete memory hog and I couldn't possibly use an array of 500000x500000. I bet they were optimizations that covered this problem, but I was miserable so I just
patched up my own messy algorithm. What would it do? It would randomly select a 100 characters long string from the current content and search for it in the previous content. If it found it, it would expand the selection and consider it a Reasonably Long Common Substring and work from then on recursively. If it didn't find it, it would search a few times other randomly chosen strings then give up. Well, actually is the same algorithm, made messy and with no extra memory requirements.
It worked far better than I had expected, even if it clearly could have used some optimizations. The code was clear enough in detriment of speed, but it still worked acceptably fast, with no noticeable overhead. After a few tweaks and fixes, the class was ready. I've tested it on a project we are working on, a big project, with some complex pages, it worked like a charm.
One particular page used a control I have made that allows for grid rows and columns to have children that can be shown/hidden at will. When collapsing a column (that means that every row gets some cells removed) the compressed size was still above 50% in up to 100 patch fragments. When colapsing a row, meaning some content from the middle of the grid would just vanish, the size went down to 2%! Of course, putting the
ViewState into the session also helped. Gzip compression on the server would complement this nicely, shrinking the output even more.
So, I have demonstrated incredible compression of
UpdatePanel content sent through the network with something as small and reusable as a response filter that can be added once in the master page. You could use it for customers that have network bandwidth issues or for sites that pay for sent out content. It would with sites made with one big
UpdatePanel placed in the
MasterPage as well :).
If you want to use it in your sites, please let me know how it performs and what problems you've encountered.
This annoying error appeared out of nowhere in a project that used to work. I thought that the fault was of the new AjaxControlToolKit and the way it tries to register a CSS file. I was about to make really complex and , apparently, useless changes to my code until I've stumbled upon Rick Strahl's blog. It is not in the entry, but further down in the comments, but it's there.