Meatball's Guide to .NET » JavaScript http://rogerpence.com/blog A dogma-free guide to making real-world sense of .NET Wed, 23 Jun 2010 16:15:35 +0000 http://wordpress.org/?v=2.8.4 en hourly 1 Avoid non-FireFox browser issues with Firebug’s console object http://rogerpence.com/blog/index.php/archives/319 http://rogerpence.com/blog/index.php/archives/319#comments Thu, 21 Jan 2010 15:57:34 +0000 admin http://rogerpence.com/blog/?p=319 The Firefox Firebug add-in is a superb JavaScript debugger. If you’re writing, learning, or debugging JavaScript (and if you’re doing the first two, you’re certainly doing the third!), Firebug should be in the top drawer of your JavaScript toolbox.

One of the Firebug features I use a lot is its console object. The console object lets you emit messages from your code to Firebug’s console. For example, console.log( n ); emits informational message n to the Firebug console while console.error(n); emits error message n to the Firebug console. This console is very handy, especially in your JavaScript unit testing code. While Firebug doesn’t have a steep learning curve, some of its features can sneak up on you. If you haven’t yet dug into Firebug’s console, do so soon!

A challenge that the Firebug console presents is that to use it requires that you pepper your code with Firebug-specific code that will cause the code to break in other non-Firefox browsers. For production work, you’ll probably want to comment out or remove console lines.  However, I want to run my JavaScript unit tests in several browsers and don’t want to have to change the test code to do so.

Firebug’s creator, Joe Hewitt, posted a nice little chunk of code (shown below) that maps Firebug’s various console methods to no-ops for non-FIreFox browsers. With Joe’s code in place, JavaScript tests can run in any browser. For qUnit JavaScript unit testing code, add Joe’s code to the module’s setup method (more on qUnit in an upcoming post).

Joe Hewitt’s prophylactic Firebug console code
  1if (!window.console || !console.firebug)
  2{
  3    var names = ["log", "debug", "info", "warn", "error", "assert", "dir", "dirxml",
  4    "group", "groupEnd", "time", "timeEnd", "count", "trace", "profile", "profileEnd"];
  5
  6    window.console = {};
  7    for (var i = 0; i < names.length; ++i)
  8        window.console[names[i]] = function() {}
  9}
Show copy-friendly code

One final note: I occasionally teach JavaScript. Joe’s graceful little solution to the awkward cross-browser problem posed by using Firebug’s console object makes a great little quiz for JavaScript beginners. It’s not a lot of code, but what little code there is is interesting code. When someone can explain Joe’s code clearly, I know they are ready for the next notch in their JavaScript programming belt.

]]> http://rogerpence.com/blog/index.php/archives/319/feed 0 Using jQuery to work with ASP.NET-munged HTML elements http://rogerpence.com/blog/index.php/archives/263 http://rogerpence.com/blog/index.php/archives/263#comments Tue, 06 Oct 2009 21:13:00 +0000 admin http://rogerpence.com/blog/?p=263 ASP.NET (pre-ASP.NET 4.0, that is) makes it a point of munging control IDs by forcing a fully-qualified naming scheme on both the resulting HTML element’s ID and Name attributes. For example, a TextBox named textboxName, when placed in a user control used on a content page with a master page gets rendered like this at runtime:

Figure 1. HTML element with munged ID and Name attributes.
  1<input name="ctl00$ContentPlaceHolder1$ctl00$textboxName" 
  2       id="ctl00_ContentPlaceHolder1_ctl00_textboxName" 
  3	      type="text" />
Show copy-friendly code

It’s often desirable to dynamically associate either behaviors or cosmetic styling to these elements, but because of the munged ID, locating these elements, especially with bare-naked CSS selected is challenging (unless you hard-code special case CSS class names).

jQuery makes the selection of such elements quite easy. Because the munged IDs always end with the control’s base name, you know that the resulting HTML ID will end with that control name. Here’s how to use jQuery to select these elements based on the ending value of their ID.

First, add a reference to jQuery in the master page’s <head> section. (In this example, I’m pulling jQuery from the Microsoft Ajax Content Delivery Network.)

Figure 2. Add a reference to jQuery in the section of the master page.
  1<script src="http://ajax.microsoft.com/ajax/jquery/jquery-1.3.2.min.js" 
  2        type="text/javascript"></script>
Show copy-friendly code

To locate an HTML element with a munged ID, use the jQuery AttributeEndsWith selector. This selector finds all elements where the given ID ends with a specific value.

Figure 3. Add this JavaScript to the content page.
  1<script type="text/javascript">
  2    $( function() {
  3        $( "input[ id$='textboxName']" ).val( "prove this." );
  4    });
  5</script>
Show copy-friendly code

The example above selects the input element that ends with “textboxName” and sets its value to ‘”prove this.”

jQuery’s AttributeEndsWith performs a brute-force traversal of all of the tags specified (and applies a regular expression against the ending value provided) so this technique may have some potential performance issues, but my experience with it hasn’t shown any glaring degradation.

rp

]]> http://rogerpence.com/blog/index.php/archives/263/feed 1 JavaScript: The Joe Walsh of programming languages http://rogerpence.com/blog/index.php/archives/97 http://rogerpence.com/blog/index.php/archives/97#comments Tue, 14 Jul 2009 16:21:11 +0000 admin http://rogerpence.com/blog/index.php/archives/97 When ASP.NET debuted one of the improvements it brought to Web development was the way in which it hid away lots of painful, aggravating JavaScript. For a long time we thought that was a virtue. None of us liked JavaScript back then. It was fiddly, hard-to-debug, and required (or at least seemed to require) black magic incantations to work correctly.

Then along comes Ajax and does for JavaScript what the Eagles did for Joe Walsh. The promise of rich (or at least richer) user interfaces was quite alluring and that and better JavaScript-centric tools and books quickly made us reconsider JavaScript. While JavaScript still has warts and hairs, its singular role as the ubiquitous browser programming language trumps those problems. JavaScript is clearly with us for the long haul. Understand this:If you don’t know JavaScript, you aren’t a Web developer! There is no avoiding the importance and impact of JavaScript. It is very important to at least achieve an intermediate level of JavaScript if you intend to write browser-based applications.

As ubiquitous as JavaScript is, I often bump into very bright VB and C# coders who don’t know much about JavaScript. This is the first is a series of articles that explains JavaScript for VB and C# programmers. I’m not going to try to provide the definitive JavaScript tutorial; the Internet doesn’t need another one of those. There tons of great JavaScript resources available (see the reference links at the end of this post). What I am going to present in this series a few JavaScript basics that have helped me. I’ll also introduce you to some JavaScript tools and techniques that work well for me.

Elusive language

For a VB or C# coder, JavaScript is a sneaky, elusive language. Syntactically, it grows from the same curly-brace, semi-coloned roots that C#, C, and even Java does. However, to master JavaScript you quickly need to learn that JavaScript is very much a different language than either C# or VB. The differences are subtle because JavaScript, especially the JavaScript written by rookie JavaScript coders, can indeed behave very much like imperative C# or VB. But, as we’ll see, behind the JavaScript curtain lurks some functional aspects that are very powerful, but easy to overlook. We’ll get to those later; let’s first focus on a few basics.

For the purposes of these posts, I’m going to assume at least a passing syntactical knowledge of C#. If you’re a VB coder with minimal or no C# knowledge, the examples I’ll provide here should be short enough that you’ll be able to intuitively grok the syntax.

Dynamic typing

Let’s start first with a simple JavaScript example. Figure 1 below shows a simple JavaScript function that apparently returns the sum of two numeric values. And indeed it does if both arguments passed to it are numeric values. With this code, you can quickly see the initial syntactical similarity that JavaScript has to C# and Java.

Figure 1. A simple JavaScript example
  1var z = sum( 4, 8 );
  2
  3function sum( value1, value2 )
  4{
  5    return value1 + value2;
  6}
Show copy-friendly code

However, unlike VB and C#, JavaScript is dynamically typed. As such, notice that in the code in Figure 1 JavaScript types aren’t explicitly declared for any variables or functions. Neither z, nor value1, value2 nor even the type that is returned by sum() are, or can be, declared. Note that .NET 3.5’s C# and VB’s var keyword, despite its looks, does statically type a variable. JavaScript is doing no such thing with its var. JavaScript’s var is truly dynamically. Given JavaScript’s dynamic typing, z can be a numeric value but then later be a string, as shown below in Figure 2:

Figure 2. JavaScript is dynamically typed
  1 z = sum( 4, 8 );
  2
  3 z = “Neil”
Show copy-friendly code

Give this dynamic typing, it’s possible to call sum() with arguments of types other than numeric as shown below in Figure 3:

Figure 3. Sum()’s arguments aren’t explicitly typed
  1var z = sum( “Neil”, “Young” );
Show copy-friendly code

The call in Figure 3 returns the concatenated result “NeilYoung.” JavaScript would even let you call sum() as shown below in Figure 4:

Figure 4. Dynamic typing in action again
  1var z = sum( “Neil”, 8 );
Show copy-friendly code

where the result would be “Neil8.” Interesting, huh? JavaScript has the innate ability to dynamically coerce types when necessary. In the case of Figure 4 above, the numeric value 8 is coerced to string to produce the concatenated string result. But wait, it gets more interesting. Guess the result of Figure 5 below:

Figure 5. Dynamic typing in action
  1var z = sum( “6”, 8 );
Show copy-friendly code

That’s right, it’s “68.” Now, guess the result of Figure 6 below; it’s a little trickier:

Figure 6. Attempting explicit casting
  1var z = sum( 0 + “6”, 8 );
Show copy-friendly code

In this case, the result is “068.” As I was learning this, I would have bet you a paycheck that the 0 + “6” would have resulted in a coerced numeric value of 6, but that isn’t the case. Like VB and C#, the + sign means either arithmetic addition or string concatenation. If there is a string somewhere in the expression, JavaScript always assumes the + sign means string concentration. Getting sneakier, consider the output of Figure 5 below:

Figure 7. A way to explicitly cast a string to numeric value
  1var z = sum( 1 * “6”, 8 );
Show copy-friendly code

In this case, because the * sign has only one meaning, arithmetic multiplication, the 1 * “6” does indeed get coerced to the numeric value 6 and the result of calling sum() as shown in Figure 7 is the numeric value 14. If you try an arithmetic operation against the wrong type (eg, 1 * “A”) then JavaScript returns a special value named “NaN” indicating that the operation couldn’t be performed on non-numeric values. I’ll discuss NaN later in a post about JavaScript error handling.

We’ll see later that JavaScript has a few other explicit type conversion options available to it. We’ll also see that JavaScript has the ability to test the types of variables so that you can build in a little type-safe protection when it’s needed. Note though, the impact that JavaScript’s dynamic typing has on function naming. The name sum() for the function above (at least as it is currently written) is a poor name for that function because it can do more than just the numeric operation implied by the name “sum().”

Unusual variable scoping

Variable scoping in JavaScript has two levels to it: an easy, pretty obvious level and another richer but more complex level. This second level has to do with JavaScript closures. Closures are beyond the scope of this post, but will be covered in another later. For now let’s consider the basic implementation of JavaScript variable scoping.

When you declare a variable with JavaScript, the var keyword is optional (although is should be required!). For example, Figure 8 below declares variable x

Figure 8. Declaring a variable with the var keyword
  1var x = 89;
Show copy-friendly code

as does the line below in Figure 9:

Figure 9. Declaring a variable without the var keyword
  1x = 89;
Show copy-friendly code

Both lines declare a variable x, but there is a difference. When you use var to declare a variable, that variable is scoped either globally to all functions (if it’s declared outside of any functions) or scoped to the function in which it’s declared. Let’s look at a few more examples. If you omit the var keyword, you are implicitly creating a global variable—regardless of where the declaration takes place. I’ll get back to this in a minute—but let it register now that declaring a variable in JavaScript without var is generally a very bad thing to do!

Figure 10 below shows a global variable x being declared. Because x isn’t owned by a function, its value is available anywhere. Remember, too, that global Javascript variables are available to all other JavaScript files used by any one page. Global truly means global in this case.

The example below shows x being assigned to the scopeTest()’s variable y which, because the var keyword is used, is available only inside scopeTest().

Figure 10. Declaring a variable outside the bounds of functions
  1var x = 89;
  2
  3function scopeTest()
  4{
  5    var y = x;
  6}
Show copy-friendly code

Because x is global by virtual of not being declared inside a function, the use of var in line 1 in Figure 10 above is option. Had line 1 omitted the var keyword, the behavior in Figure 10 would not have changed. Having said that, the var keyword doesn’t change the global behavior (because x is declared outside the bounds of any functions); you should always use the var keyword.

If the code in Figure 10 were written as shown below in Figure 11, the variable y declared in scopeTest() is global (because it isn’t declared with the var keyword). The interesting thing about the y variable is that it isn’t available to the rest of the program until scopeTest() has been called once. Therefore, the code below will fail at line 3 (where writeLine() is a diagnostic function to display a variable we’ll discuss later) because testScope() hasn’t yet been called.

Figure 11. declaring a global variable in a function
  1var x = 89;
  2
  3writeLine( y ) 
  4
  5function scopeTest()
  6{
  7    y = x;
  8}
Show copy-friendly code

However, anytime after a call is made to testScope(), then the global variable y it declared is available to the rest of the JavaScript program. Figure 12 below will now correctly display the value of the global variable y.

Figure 12.Referencing y
  1var x = 89;
  2
  3scopeTest();
  4
  5writeLine( y );
  6
  7function scopeTest()
  8{
  9    y = x;
 10}
Show copy-friendly code

JavaScript variables are not block-scoped

Remember that variables are not blocked scoped in JavaScript like they are in C# or Java; rather in JavaScript variables declared in a function are scoped to all of the code in that function. Therefore, what appears as though it should be a variable private to the if block below is really available from where it’s declared on down in the function. Figure 12 below shows this.

Figure 12. JavaScript local variables are block-scoped
  1function scopeTest()
  2{
  3    // Variable x is undefined here.
  4    if ( condition )
  5    {
  6        // Variable x is available beyond the 
  7        // if block’s scope. 
  8        var x = 89;
  9    }
 10    // Variable x is available here!
 11}
Show copy-friendly code

As you can imagine, bad things can happen when you omit the var keyword. The general rule of this is don’t ever omit it! If a variable needs to be global, don’t declare it inside a function, declare as an inline variable. Note also that the dynamic nature of JavaScript can get you in big trouble quickly if you aren’t vigilant. Consider the code below in Figure 13:

Figure 13. JavaScript doesn’t have Option Explicit!
  1Function scopeTest()
  2{
  3    var myRate = 89;
  4    Myrate = myRate + 100;
  5}
Show copy-friendly code

In this case, I meant to increment the value of myRate by 100. However, I got the case wrong on line 2 spelling Myrate instead of myRate. So, without any fanfare, JavaScript sees that not as an error, but rather as my desire to declare a second global variable named Myrate. Not only was myRate not incremented as needed but I also got a free global variable out of the mistake. And, this is important, myRate has an incorrect value with JavaScript providing no clues as to anything being amiss.

For my money, the ease with which a coder can make such a simple, profound mistake is why JavaScript got a bad name in the first place. You must always be aware of case. If JavaScript had an option explicit-like setting like VB does (disallowing variable declarations without the var keyword), we’d be protected against such boneheaded, but certainly possible, errors.

While there isn’t anything built into JavaScript to help you avoid these errors, there is a superb online JavaScript utility called JSLint you can use to screen your code for such errors. JSLint investigates your JavaScript and reports lots of information about it. One of the things it reports is the sloppy use of variables as shown in Figure 13. For JavaScript work of any real merit, the use of JSLint is highly recommended.

The lesson learned: take great care with your JavaScript variable scope and naming and watch your case.

]]> http://rogerpence.com/blog/index.php/archives/97/feed 0 Great resources to help you learn JavaScript http://rogerpence.com/blog/index.php/archives/116 http://rogerpence.com/blog/index.php/archives/116#comments Fri, 15 May 2009 05:08:35 +0000 admin http://rogerpence.com/blog/index.php/archives/116 Here are some of my favorite and most frequently-used resources for learning JavaScript. I’ll update this list on a recurring basis.

Resource Description
JavaScript Tutorial
JavaScript Tutorial
JavaScript Reference Series
JavaScript Reference
JavaScript Closures 		There are more online references and tutorials for JavaScript on the Web than there are naked pictures of Paris Hilton. To find them (the JavaScript stuff, you perv), you only need a firm grasp of Google! Listed to the left are some of my favorites. Most of them speak for themselves. The first one, though, deserves special mention. Most readers will be familiar with it already, but for those of you who aren’t, be sure to bookmark W3Schools. While it has great JavaScript info, it also has loads of other great Web development info.
JSLint JSLint is an online JavaScript code quality tool. It investigates the JavaScript you paste into it and reports tons of information about it.  Perhaps the most important thing it reports is sloppy use of undefined variables. JSLint is the work of JavaScript Jedi Douglas Crockford. He promises that JSLint will hurt your feelings!
ECMAScript Language Specification While no one but the official language spec committee calls JavaScript “ECMAScript,” this 188 page manual (it’s a PDF) is quite handy. It’s dry, and probably tells you a little more than you really want to know, but it its value, especially for free, as a JavaScript reference is superb.
FireBug JavaScript debugger for FireFox
IE8 debugger
Opera Dragonfly debugger		 The combination of FireFox and Firebug has probably done more for learning and exploiting JavaScript than all of the JavaScript books ever written. The synergy of the two actually make writing JavaScript fun—and that’s an elusive word association. Both IE8 and Opera also now both offer intrinsic JavaScript debuggers that, while not as good as FireBug, are quite a step forward for these two browsers.
jQuery This isn’t just a superb JavaScript library–it’s a JavaScript game changer. Using it will improve, vastly for the better, the way you write JavaScript. The decision tree for determining if you should use jQuery is very simple: do you write JavaScript? If yes, you need jQuery.
JavaScript style guide JavaScript coding conventions per Crockford.
Douglas Crockford JavaScript videos Douglas Crockford has made several videos about JavaScript and they are very enlightening. There is a series on JavaScript and then one on advanced JavaScript. Also, do an advanced Google search for Crockford’s JavaScript PowerPoints—they are terrific.

On a slightly related note, to hear ten or so of the most awkward DotNetRocks minutes ever, give a listen to Carl and Richard welcoming Douglas to their show #422. Listen for a couple of minutes about 9 minutes into the Podcast. Richard’s uncomfortable laughter will make you cringe and Carl trying to explain away his Wierd Al reference draws dead air. I’m generally a big fan of DNR, but this interview had me wishing for a flat tire on my way to work just for an excuse to stop listening. An opportunity to interview a JavaScript god was completely pissed away. To Carl and Richard’s credit, Crockford does come across as a bit of a mooncat. He remains pretty much disengaged throughout the entire interview.
headfirstjavascript This is a good JavaScript book for beginners. The Head First books flirt with being just a little too pretentious (they are a little like a Dummies book gone nearly right) but overall the info in the book overcomes some of its “mom made me a JavaScript scrapbook” impact.
javascript_the_good_parts One more Crockford reference and I swear I’m done with him (for now). JavaScript: The Good Parts is a very good book on intermediate/advanced JavaScript. If you’re new to JavaScript, don’t make this your first book. But once you think you’ve got a a handle on JavaScript, this book will definitely ramp up your JavaScript knowledge more than one level.
]]> http://rogerpence.com/blog/index.php/archives/116/feed 0