blog-j: Symbolizing, Coding, Objectifying, Processing

Javascript. A word that invokes feelings both marvelous and dreadful. On the one hand, it’s a powerful scripting language, and in modern browsers there’s a whole heckuva lot we can build with it. As far as the actual language goes, though, there’s lots to be desired. Utilizing OOP in Javascript is a pain in ass at best (remember prototype chains in Actionscript 1.0?), and language constructs are minimal - the lack of syntactic sugar in javascript could possibly be better called Syntactic Tabasco - it’s there, it’s hot, and it just doesn’t make things sweeter (yes, I do love Tabasco, but I don’t generally put it on my cupcakes, if you know what I mean).

Enter Nikhil Kothari’s Script# (that’s pronounced Script Sharp, for those of you who either aren’t musically inclined or live under a rock, take your pick).

Script# brings the C# development experience (programming and tooling) to the JavaScript/Ajax world.

The Script# compiler is a C# compiler that generates JavaScript as its output instead of IL. A key goal of the compiler to produce readable JavaScript (as if you had authored it by hand), and would be comfortable deploying into real apps. Hence the translation works from C# source directly into JavaScript without an intermediate IL layer. The compiler can also produce equivalent, but much more compact script for use in release mode deployment. The compiler does not introduce any additional levels of abstraction, thereby allowing you full control of what your application does. In essense the best of script with the best of C#!

I’m hoping to get a chance to play with this in the next little (short) while, but from what I’ve seen it’s pretty damned cool. Just having the compile step is pretty schweet - I’m a big fan of compiler errors over runtime errors, and runtime errors in Javascript are usually pretty painful (granted, that’s dependent on the browser, and there are lots of tools out there that make it better, but anyway…this is my blog, not yours - feel free to espouse “Notepad only Javascript development” on your own blog; for me, I’ll at the very least be using Notepad2).

And, of course, you already know I’m a big fan of C#.

Links:
Script# Project Page
Introduction to Script#
Script# and LINQ

I think I’ve mentioned this extension before (got pointed to it by Chris, and have been using it happily since. Instead of trying to come up with a witty description of what it does, I’ll quote:

Once you have installed Aardvark as an extension (as opposed to running the demo), start it by right-clicking on the page and choosing “Start Aardvark” from the menu. The extension will run until you leave, refresh, or stop it by pressing “Q” for quit.

As you glide the mouse over the page, you will see a red rectangle framing each element under the cursor. You will also see a little yellow caption showing the HTML element type and its class or id if they exist.

Now, that comes in hugely handy when developing sites. Go figure. So you’ll imagine my dismay when I installed Firefox 2 last week and…whammo…no more Aardvark. Man. I’ve been on a mission since (ok, maybe not so much of a mission as a kind of get-frustrated-do-nothing-about-it). Decided I’d try again tonight, thought to rename the .xpi to .zip and see where I could get. Turns out I was on the right track. After “hacking” through the zip (and by hacking I mean looking at all the files and wondering which one I should edit to make the sucka work), I decided that maybe I’m not as smart as I think I am and that asking Google has usually helped me in the past and maybe now would be a good time to try that.

Deep breath.

Voila. Someone else seems to have been frustrated by this. And there is now an unofficial build of the Aarvark .xpi for you to install on your FF2 installation…

The Aardvark Firefox Extension
Getting Aardvark extension to install in Firefox 2
How To Update (Some) Firefox Extensions For Firefox 2.0 *

Happy Foxing.

* - And I just read through the comments there - apparently there’s a tool that force-activates all FF plugins, regardless of compatability. I suppose this will only help if you’ve upgraded your installation (as opposed to a fresh install of FF2), but anyway…check it out @ users.blueprintit.co.uk/~dave/web/firefox/nightly

One of the neat things about the ASP.NET Page class is the RegisterClientScriptBlock method (the RegisterStartupScriptBlock is also cool, and this here tip applies just as well to it). What the RegisterClientScriptBlock method does is add whatever script you pass to it to page, and register it with a key, such that a script is only added to the page once (assuming you only want it added once). The signature for the method is:

Ok, wait. I missed something. Damn.

It seems that in ASP.NET 2.0 this method is obsolete, replaced with the [Page.]ClientScript.RegisterClientScriptBlock method (Page.ClientScript is an instance of ClientScriptManager, nice little refactoring for you...), signature as follows:

[Actually, there's a bunch more that the ClientScriptManager class does (well, instances of said class, anyway) - more info on the msdn]

What I was going to say is that it always irks me coming up with a key for the script block. And using the Type as the key makes a bit of sense (until, of course, you get into multiple script blocks being registered from a single page, control or Type). Regardless, it could be used as a base, eg:

And then, bam! - you wouldn't have to think about it, and there'd be very little chance of name collisions. Which is, I assume, why the engineers of the BCL (particularly the System.Web namespace) refactored the method - the key gets duality (between the Type passed as well as the string key), and hence very little chance of name collisions.

I'm sitting through Fritz Onion's workshop on ASP.NET development, and I noticed he was using GetType() in the RegisterClientScriptBlock. I neglected to notice that he was not calling it directly on the Page object (rather, on the ClientScript property of the Page object). It's a good thing I'm so thorough and checked the method signature, saw the obsolete attribute, and gave you all the real deal. Nevertheless, if you're still coding ASP.NET 1.1, it's not a bad option.

Of note is that it would have been cool if they had added the ClientScript property to the Control class, as a shortcut to the Page's ClientScript property. Not absolutely necessary, I suppose, but I think it's a bit cleaner to have:

...instead of (replace line 7 above with this):

[note: the latter method works - the former doesn't.]
Though I suppose there are reasons for that (for example, since Page extends Control you would end up with some ambiguity, as the Control class has a Page property, which, in the Page class, references the Page, which would mean they would have to override ClientScript in the Page class, which makes no sense. And, as you know, I'm don't believe in ambiguity. Unlike the sentence just before the last one.

Over'n out.

One of the cool things about C# is the way it handles "properties". When writing set statements, there is an implicit argument named "value" that holds the value passed to the property. Hence, within your implementation of the property, to get the value passed to the property you use the "value" variable, like so:

What's good about this? Well, you just didn't have to think of a name for the variable, like newName, or new_name, or name. Which shaved precious seconds of (wasted) thought off your coding.

Can we do this in Actionscript? Well, not exactly - there's no language support for it. But, if you think about it (and stop thinking about it), you can do it quite easily: use "value" as the name of the variable passed to every set method you write for the rest of your life.

This has a secondary (though equally if not more important) effect: it forces you to ensure the name of your property is sensible. You shouldn't need the parameter name of a property to clarify the intent of the property. If you do, you'll probably want to rethink your property name, which is way more important than deciding between new_name and newName. After all, when someone else is coding with or to your API, you don't want them to have to think about it, right?

Heck, take it a step further and use it in Javascript, too. Just for the fun of it.

Have a great weekend...

Joe Duffy gives us some thoughts on AJAX vs. Rich Clients (eg: desktop apps communicating with "web data"). Interesting (if short) read. One line in particular jumped out at me (I'm biased, admittedly):

This is where technologies like Flash/Flex come into play, taking the web experience and incrementally improving it to deliver richer experiences.

It's interesting hearing this from someone at Microsoft (Joe is the PM for the CLR). Methinks someone should introduce him to Apollo, too. Definitely suggests that people seriously see the value of Flex and Flash in the long term, even with so offhanded a reference (or perhaps because of offhandedness of the reference...?).

Read the post @ bluebytesoftware.com/blog/.

The fight is on!

No, ok, really it's not. I have yet to find many ASP developers who use server side JScript. Which sucks for them, because, you guessed it, VBScript is just about the most horrific language to work with if you actually want to do anything other than spit something out onto a page.

Ok, maybe that's a bit harsh. Let's just say I don't really enjoy working with VBScript (or VB, for that matter). I'll let you come to your agreements with your VB-loving self.

I do have a point. Stick with me. (Ever notice I say that a lot? Most people think it's the ADD. Me, I think it's the ADD, to hell with what everyone else thinks. Though it could just be senility. Or Mad Cow.)

Anyhow.

One of the cooler things about (classic) ASP is the ability to utilize multiple languages within a single page. Which means you can write classes and shtuff in JScript, include them (or inline them), and use VB in the body of the page, calling the classes, functions, and variables you wrote in JScript from the VB portion of the pages. Once of the interesting things about doing this (and, actually, a rather large caveat) is that all the JScript on the page is executed first, then the page is handed off the VB engine.

Why's that interesting? Well, imagine you have a simple page like so:

(Note that wordpress seems to want to sanitize my code above - there are some additional spaces on some of the server side tags)

So, what do you think the value of myNumber is when it gets spit out to the page? If you payed attention above, you'll get it right.

That's right. The value of myNumber is 5.

Try executing that on a Windows server somewhere. Or you can view the output here. You'll note that the JScript comment is right at the top of the page output (view source, baby), not inline in the page as the VBScript comment is.

Eeenteresting.

Stay tuned. I'll be back tomorrow with some of the ways this can be uber useful.