I am a great believer in client side web programming. I find the whole "everything on the server" approach to web design to be a bit crazy given the immense power of the average client machine these days. P4 1Gb Ram , back in 1985 you would have thought you could have run the worlds stock markets with that sort of power.
The issue with client side web programming is that peoples bad experience will java applets (slow to load) an activex controls (Security: I once wrote one that would format your hard drive just by visiting a page) means that today alot of developers seem to have an avertion to the concept.
I personally think that javascript and DHTML are brilliant, and add in AJAX and you literally have an entire data-aware programming environment ready for action. So what do most web developers do. ??.. Ignore it , load up their server with all the work and watch their website grind to a halt !!
Anyway enough ranting..
Two of the areas of web application development that can get huge performace (and user experience) gains from moving to client side processing are:
1. Drillable reporting and charting.
2. Dynamic Office Document Creation.
For now I will leave client side drillable reporting until another post and focus on Dynamic Office Document Creation. When I say "Dynamic Office Document Creation" I mean something like dynamical making an Excel Spreadsheet or a mail merged Word document.
Dynamic office document creation is pretty much the realm of the server these days, and most of the time people install some sort of 3rd Party tool on their web-servers to do this. As you can imagine these sorts of things are pretty resource intensive for the server especially if you are producing large documents. Also because the documents are created on the server they then have to be downloaded to the client; and these documents tend to be 1000x larger that the original dataset.
Lately I have been thinking of an idea of how this could be moved to the web client to off-load it from the server and lower the bandwidth requirements. I have come up with an idea that requires just the Browser and the Target Office application.
Here is the basic idea; Lets say I want to create a mail merge document of a standard letter using data stored in an SQL database via my web app. I do the following:
1) Create a web page that allows the system users to query the address data they want in the mail merge.
2) In the search results page have a hidden Textarea that also contains the returned data, but in a tokenized format (xml is good , but any tokenized format will do).
The form also contains a button that does the following.:
a) Loads the contents of the hidden textarea element into the clipboard.
b) Redirects the user to the Mail Merge word document that contains the code to do the mail merge work.
The IE javascript code for this is:
function IE_ClipBoardandLaunchDoc()
{
//htext is the hidden textarea where the server built the tokenize data
// <textarea id="Datatext" style="DISPLAY: none">….. data ….</textarea>
var htext = document.forms[0].Datatext;
Copied = htext.createTextRange();
Copied.execCommand("Copy");
alert('When the file download dialog box appears press "Open".This will launch word and display the document. Click the \'Merge Me\' button to perform the Mail Merge.\n\nPlease make sure you have macros enabled in word or the document will not be built');
document.location = 'SampleMerge.doc';
}
( I don’t use firefox/mozilla so I don’t have a version of this code for those browsers. But if you care you can probably work it out from here
http://developer.mozilla.org/en/docs/Using_the_Clipboard or
http://www.jeffothy.com/weblog/clipboard-copy/ )
3) Create a word document that has the body of the standard letter and all of the fields that need to be filled in. Add to the bottom of this document a button that when clicked will.
a) read the data from the clipboard and de-tokenize(parse) it
b) create a merge datasource from the data
c) perform a merge against the document and the newly create datasource.
Here is an
example of this in action.
