ASPX .NET - Code In Front

This horn has blown. It blew a long time ago (that's a link to my Engine project, in case a hint was needed). That's a whole lot of horn blowing, espousing the need for a client-side framework to better serve Web applications. Did I mention there has been a lot of brass blowing? Try as I might, I could never really find a target audience that subscribed to my seemingly esoteric project. Along comes Google with their very nifty auto-complete via a Web service, and suddenly the Web is abuzz with acronyms like AJAX. And, I'm sitting back looking at my little project, feeling just a bit misunderstood. Granted, Google came out with those Gee-Whiz features, and I'll give due credit because they were very sharp.

On the other hand, there's AJAX: Asynchronous JavaScript XML. I'm rather tired of acronyms, so I don't have any vitriolic disdain for the article or its author. Instead, what unnerved me was that I've been promoting a very similar topic for five years, and have been actively working on a project to facilitate this move for going on three years.

Let's set the machine back for three years. I'm sitting in a ten-hour test-install session of some rather ugly beta software, boredom squeezing tears from my eyes, and making notes. At that point, I had gone about as far as I wanted to go with DHTML MDI Windows, and I had been running into road blocks. The notes were the roadblocks - all the things I thought I should have been available before I started working on a redesign of the MDI library. Move the dial ahead a few months. I started some side-work with a young company on a project that, surprise surprise, was exactly what the AJAX article describes. Except, in that case, it made a disgusting display of DHTML Behaviors - not that I was ever that big of a behaviors fan, mind you, but this was just a ludicrous mash of Java and general engineering-speak ground into JavaScript and slapped inside the CDATA block that we know as a DHTML behavior. A lot of the points I had in the notes were raised as central arguments against the design: there was no underlying FRAMEWORK to adequately support the script-heavy application UI. I'm bolding that because framework is an overused and overweight word, but in this particular case it's weight was gold. Or, at least silver. Maybe just blackened copper. But it had some kind of weight.

Around that same time, I decided to keep notes on the design decisions. Why, exactly, did I feel the need for some complex library that had no flash or Gee-Whiz features? Because, at the time, I thought it would make it that much easier to create the flashy and whiz-bang doohickeys. I still think so. Another note was related to ASPX. But, first, we'll go back to 1999/2000. I saw the early versions of ASPX, and I was stunned. Not a good, euphoric taser-to-the-gonads stun, but a wavey-nausea that-homebrew-was-bad stunned. ASPX kept sending users round-and-round to the server. Why? Microsoft was readily employing XML, and making use of it in many places, so why not leverage Internet Explorer and provide a way to take that code behind and transmogrify it into code in front? Was something missing? Like, perhaps, a ready-to-use, no-scripting knowledge needed, drop-in library? Or, something like AJAX? Ahem.

So, I decided to see how hard it would be to finish my little two-step of using the Engine for Web Applications framework to do exactly that: remove the full-page reloads while still allowing downlevel browsers to use the application, and allowing developers to make as minimal changes to their code as possible. And, after a few hours, I'm happy to report the experiment a success and want to take this opportunity to further grouse about AJAX by saying developers shouldn't have to worry about it, it should just work. And, that's what I did and what I now have.

Here's the breakdown.

Before starting, and feeling a bit frisky, I started out with the most absurd acronym I could think of by naming the whole demonstration DARTH SITH for DHTML Asynchronous Remote TeleHarness Script Invocation and Trinary Handler. It had to compete with AJAX, after all, and it had to strike a warm-fuzzy with the developer community. Seconds later, I realized that was just dumb, so I called it ScriptJack until I could think of something else. Nothing else came to mind, so ScriptJack it remains.

First, I had to fix up some dormant bugs in my code. Most of this entailed adding accessor methods to obfuscated properties. In the end, I cleaned up my implementation making these changes moot. Well, at least they're now fixed.

Second, I created two generic Application Components (Example). The first component would handle objects being registered for CodeInFront, and the second is a transactional component, script-jack, that receives transacation volleys from the CodeInFront and uses the global variable to post XML requests back to the server. The important point to note here is that even in this thrown-together example, developers don't need to change anything. They may, of course, but it isn't necessary.

Third, I created a basic Web project in Visual Studio, added a few buttons, and declared the acid = "CodeInFront" attribute for a few of them. Some were HTML INPUT fields, and some were ASPX Web Button controls. The button controls had server-side click events, and the HTML buttons did not. On one of the HTML buttons, I added a custom method name to invoke on the server, just for sport.

Fourth, I added three static script elements to the top of the HEAD: 1) load the engine library, 2) load an initializing script to turn on the engine, and 3) a global variable to echo the raw URL and include a query parameter named post-xml. Of course this could be a lot cleaner, but this was just an exercise.

Fifth, I pasted a standard Engine wrapper (a DIV element plus some custom attributes) around the ASPX form. Doing so takes care of all the internal hookups.

Sixth, I created a class I called ScriptJackBase - because a pithy name or acronym on par with AJAX escaped me; see above remark about DARTH SITH - to handle the XML request, serve back an XML response, and delegate events to the event handlers, a handler specified in-line with the HTML element, or a default handler.

From an implementation standpoint, a developer could take this example, complete steps #4, #5, and the attribute in #3, use the ScriptJackBase class for the slightly customized URL, and have immediate gratification.

The effect of the demonstration is as interesting as it is simple. For maximum effect, try this: run the demonstration using the Visual Studio debugger, and add a break on one of the event handlers, such as Button1_Click. Then, click Button1 in Internet Explorer (it is started when running in debug mode). The break point on the event handler lights up, but there wasn't a full round trip to the server. The ScriptJackBase class took a stab (a pretty blind stab, what, this being a demo and all) at guessing the name of the event handler, or using the specified handler, and invoked a delegate to that handler. The class also takes care of generating the XML response to send to the client, and this is ripe for passing information back and forth. Granted, it's not a web service, but it works in both Internet Explorer and Mozilla-based browsers (eg: Gecko, Firefox).

That's code in front, baby.

Here's a zip of the ASPX demo: ScriptJack.zip. You'll need IIS to run, and Visual Studio.