Category Archives: web/dev/tech

Okay, I’m not really sure Microsoft invented AJAX, but I do know Internet Explorer had several asynchronous scriptable technologies and techniques long before any other browser.

To enumerate:

• DSOs (ADC, TDC, RDS).  The TDC was pretty good, ADC was too heavy, and RDS was too much of a security issue, but they were all early ways to asynchronously data-bind elements at the browser.  They were also fully scriptable.
• IFRAMEs – IE4/1997 or newer had IFRAMEs (Netscape 4 did have ILAYER, but Netscape 4 generally sucked).  I actually thought I invented this technique, and used it on many projects to much success.
• Java – Meh, too bad about the JVM.  Same basic technique, though.
• XMLHTTPRequest – Slightly more recent (circa IE5/1999 I think).  This object IS what modern AJAX code runs on.  Firefox, et al have only added similar objects in the last couple years.

“Remote Scripting” was Microsoft’s term for this technique.  (Heck, here’s an April 1999 MSDN article on the topic).

SO, I’m rather annoyed when well-known journalists say Microsoft is working “Not to be left out of any development trends…”, or better yet,
“Microsoft has decided [Ajax] is something it can’t ignore… the Redmondians have jumped on the Ajax bandwagon.”.

…Microsoft built that bandwagon.

Update: Perhaps I’m not the only one annoyed they’re not getting their due.
Scoble’s got a good laugh over AJAX, and Scott Isaacs has
thoughts on an AJAX (DHTML) framework.

Yes, this sounds like an all-too-familiar “Intro to Web Scripting” class or article, but I haven’t actually seen these more advanced scripting topics compared before, so I wanted to nail it down in print. 

Yes, of course it’s my opinion, based on experience (and frustration!)  Feel free to proselytize me otherwise, but back it up!

My perspective is this: scripting languages are about convenience — quickly whipping out something that works, is readable, and is maintainable.  If you want perfect academic code, or fastest performance, get another tool!  For scripting languages, the less code and reference to accomplish a task, the better.

Interestingly, different scripting languages reach convenience by different routes.  For example, where VBScript chooses a “simple” route of a bunch of unorganized global functions, Javascript groups them as methods of intrinsic objects.  Normally I prefer simple, but Javascript’s better organization makes me more efficient: I don’t have to remember 90 or so distinct global functions — if I can simply remember the object (Date/Array/whatever), then I’m set, because VS.net’s Intellisense will help me quickly find the method I need without cracking a reference.

(Aside about Intellisense: it reminds me of the tabs -vs- spaces debate: I say tabs all the way.  Any decent code editor should be able to display tabs how you like.  Fewer characters to store/send, and less arrowing around pays for itself.  And yes, a coder should be using a decent code editor!)

To be clear, I favor neither VBScript or Javascript as a rule — each has its time and place (goal of this chart).  Ideally, I’d like to marry them for the best of both.  Both Classic ASP and WSCs can use both in the same context, which rocks.  Too bad ASP.net lost this feature, but it matters less since it now runs full-fledged programming languages.

Finally, for entertainment, here’s a hilarious thread on the “JS-vs-VBS” subject.  My favorite quote: “IF JScript was a movie, it’d be Citizen Kane, or The Shining. VBScript would be the Mariah Carey movie, or possibly ‘Sgt Pepper’s Lonely Hearts Club Band’ starring Peter Frampton and the Bee Gees.”

Update: added ternary/IIF note to chart ‘leftovers’.

Now that I’m color-coded, I may start a regular feature here where I publish smallish code bits I’ve written…

For WSH scripters out there, here’s a handy one I wrote…

To explain, for GUI-type WSH scripts (usually run under the WScript engine), VBScript has a native Inputbox function, which prompts for user input via a dialog box.  Command-line-type scripts (running under CScript) have no command-line equivalent, though — yes Inputbox works, but a GUI dialog doesn’t really fit a command-line script.

So to fill that gap, I wrote this:

' Name:		InputLine
' Desc:		like Inputbox, but for use with cscript
' Author:	Rob Eberhardt, www.slingfive.com
' Params:	prompt as string, default value as string
' Returns:	user's answer
' History:
'		2005-06-13	added default param
'		2005-02-28	created original InputLine function
FUNCTION InputLine(p_strPrompt, p_strDefault)
	call Wscript.Echo(p_strPrompt & ":")
	IF p_strDefault<>"" THEN CreateObject("WScript.Shell").SendKeys(p_strDefault)
	DIM strInput
	Do While Not WScript.StdIn.AtEndOfLine
		strInput = strInput & WScript.StdIn.Read(1)
	Loop
	WScript.StdIn.skip(2)
	InputLine = strInput
END FUNCTION

Example usage:

DIM strChoice
strChoice = InputLine("Enter favorite color", "Red")
call WScript.Echo("You entered: " & strChoice)

…which would look like this from a command-line:

Enter favorite color:
Red
You entered: Red

For bonus points, you can detect if the current engine is CScript or WScript, and use InputLine or InputBox appropriately (like if you’re note sure what engine will run your code):

DIM strChoice

'detect CSCRIPT context & use InputLine
IF Instr(lcase(wscript.FullName), "cscript")>0 THEN	
	strChoice = InputLine("Enter favorite color", "Red")

ELSE	'detect WSCRIPT context & use native InputBox
	strChoice = InputBox("Enter favorite color", "Color?", "Red")

END IF

call WScript.Echo("You entered: " & strChoice)

Hope someone can use it.

Note: I would have absorbed this engine detection logic into a single smart InputLine-like function, if only Javascript supported Inputbox, or VBScript supported optional arguments.  But, InputBox’s optional 2nd “Caption” param makes no sense with InputLine, and unfortunately the languages leave no room to gracefully work around that.

HTTP Compression is a wonderful idea.  Unfortunately, its implementation in IIS 5 was deeply flawed. 

Besides the usual issues, I’ve also found that HTTP Compression breaks Data Source Objects (DSOs) and Tabular Data Controls (TDCs) in IE (wonderful features for client-side data-binding in web apps).  IE loads the data (showing “XX items remaining” counting down in the status bar, and eventually “Done”), but it never data-binds to the table template or gives any error messages, leaving an empty table.  My guess is that IE uses a different mechanism for requesting DSO data resources from a webserver than it does for normal resources (pages and their referenced files like scripts, stylesheets and images).  I’ve never seen this issue documented by anyone else, which I attribute to the relative obscurity of DSOs and TDCs (they were never marketed to devs enough).

So you can imagine it was a big pain figuring this out the first time…

When IIS 6 came out, I heard a lot of excitement that it fixed HTTP Compression, so I was excited too.  Well I’ve recently/finally moved into IIS 6, enabled HTML compression, and then just got confused all over again today because my TDCs were broken.  Grrr…

Sure enough, turning off “Compress Application Files” (and restarting IIS) fixed it.  At least IIS 6 gives separate compression settings for dynamic and static files, so now I’m just compressing static files (e.g. HTML, CSS, JS, VBS, HTC), which should still help a bit (of course those files are cached by the browser anyway…).

Apparently Jeff Atwood has also found other big issues with IIS 6’s HTTP compression.   He’s got a lot of good info, plus a handy metabase snippet to help fix those problems.  Check it out.