Here are three ways to get the current time in JavaScript:

var t1 = (new Date()).getTime(); // 1
var t2  = new Date().getTime(); // 2
var t3 = (new Date).getTime(); // 3

The bracket placement is as much about language awareness as personal taste. In JavaScript, the brackets are optional for a zero-argument constructor: new Date creates a new Date instance without requiring brackets. But due to JavaScript operator precedence, you can’t write new Date.getTime() because the interpreter sees that as trying to call the constructor for a Date.getTime class (cf. MyPackage.MyClass) – in this case the brackets are required for the statement to parse as intended.

Reflecting on the three versions above: Version 1 doesn’t do anything to show a deep understanding of JavaScript. Version 2 and 3 are sort of interchangeable, but version 3 just edges ahead because the coder’s displayed knowledge to drop the optional brackets.

Of course, if you want the most compact code possible, you’d write:

var t4 = +new Date; // 4

This little gem creates a new Date, then coerces it into a number using a unary + operator – and coercing a Date to a number is defined in the language spec to go via valueOf and getTime.

Checking the character-count: (new Date).getTime() is 20 characters, while +new Date is 9.

That 11 character saving might come in handy on, say, the new Google home-page, where they currently use (new Date).getTime() seven times.

Let’s do the same for cookies (source: cookie.js).

Three into one does go

Googling for ‘javascript cookie functions‘ brings back Peter-Paul Koch’s trio of functions from QuirksMode. The functions are named setCookie, readCookie and eraseCookie. Browsing through the next few search-results we see the same thing going by different names: get, set and deleteCookie; add & remove, erase & delete, read, get and check – all variations on a theme, all separating functionality into a trio of functions.

Let’s look at the method signatures:

• createCookie(name, value, days)
• readCookie(name)
• eraseCookie(name)

It’s pretty basic stuff.

To merge the three functions into one, we have to differentiate between reading, writing and deleting a cookie by the number and value of arguments; I’ve chosen an implementation where deleting a cookie is achieved by setting it to null.

Here’s some example usage:

  // create a cookie:
  cookie('name', 'value');

  // read it:
  alert(cookie('name'));

  // erase it:
  cookie('name', null);

Flexibility

All those cookie calls pass at least one parameter… but isn’t there something useful we can do with a plain parameterless cookie() call? Of course there is – let’s return an associative array of all cookie values!

By default (without specifying an explicit expiry time) cookies survive until you restart the browser. It’s kinda mandatory to provide some way of specifying an expiry time.

We’ll accept an optional third parameter specifying an expiry time in days:

  // create cookie for 1 year
  cookie('theme', 'minimal', 365);

  // grab all cookies:
  var cookies = cookie();
  alert(cookies.theme);

Looking good so far. But there’s more.

Like several of the cookie libraries, our function defaults to setting cookies on the top-level path “/” – this is a more common requirement than the browsers default behaviour, which sets a cookie so it’s only used at or below the current page level (i.e. a cookie set while looking at “/products/Nintendo-DSi-Console_Black/978372” wouldn’t be available when looking at any other product.)

To give developers flexibility I’ve made path another optional parameter – it could be used to share cookies between “/product/*” pages, but withhold them from any other area of a site.

While we’re on the subject of sharing – what about cross-domain cookies? Cookies are naturally assigned to the domain the page is being viewed on, but sometimes we want to make sure a cookie’s available to all sub-domains too. domain is also an optional parameter.

Having both path and domain as optional parameters could be confusing – after all, they’re both strings. Fortunately, we know paths begin with ‘/’ and domains don’t – and if you want to specify both you just stick to the right order: path then domain:

  // share cookie between product pages:
  cookie('view-description', 'hidden', '/products');

  // share cookie between domains:
  cookie('id', '_', '.ewelike.com');

  // save preferences cross-domain for 1 year:
  cookie('prefs', '_', 365, '/products', '.ewelike.com');

Finally, there’s an optional ‘secure’ parameter. I’ve never used this myself, but it’s there if you want it. It’s handy if you’re storing sensitive information in cookies and you only want to allow the browser to transfer the cookie value when it’s request pages via https. The code will take any truthy value hanging off the end of the parameters (anything that’s not been interpreted as expiry date, path or domain.):

  // set a secure cookie on the default path and domain
  // (expires when the browser closes)
  cookie('name', 'value', true);

Want the code? Grab it now… download cookie.js (dual-licensed under MIT and GPL, exactly the same as jQuery)

You can download sprintf for JavaScript, available under the Create Commons Attribution License. Now license free (use it where/when/how you like.)

The version I’ve written is based strongly on Perl’s sprintf implementation, allowing argument reordering to help with internationalisation (i18n). Some overly simplistic examples follow, leaving room for obvious improvements like:

1. letting the user specify their locale as a preference
2. set default locale based on visitor demographics
3. use locale-specific message-bundles with a fall-back to the default locale

On with the examples:

var locale = 'es';
var messages = {
    'en': 'I am %d years and %d months old.',
    'es': 'Tengo %2$d meses y %1$d años.'
};
var message = sprintf(messages[locale], 31, 7);

You could also use it for

var date = new Date;
var dateFormats = [
    /* ISO-8601: */ '%04d-%02d-%02d %02d:%02d:%02d',
    /* British:  */ '%3$02d/%2$02d/%1$02d',
    /* U.S.:     */ '%2$02d/%3$02d/%1$02d'
];

// for example only: choose random date format
var dateFormat = dateFormats[3 * Math.random() >>> 0];

var formatted = sprintf(dateFormat,
    date.getFullYear(), date.getMonth() + 1, date.getDate(),
    date.getHours(), date.getMinutes(), date.getSeconds());
alert(formatted);

The Perl documentation has more examples in the “order of arguments section“.
Note: this implementation allows the precision of a number to be set from a specific argument (using e.g. “%.*3$f”), which the perldocs (perldoc -f sprintf) say hasn’t been implemented yet.

I haven’t (re)written any documentation for it, but you should be able to use Firebug (or the javascript: protocol) to try out sprintf on this page, and you can also check out the test page for sprintf for more input/output samples.

As usual, writing test-cases uncovered a couple of browser-dependent issues. Safari has some bizarre behaviour with Maths.abs(0).toFixed(6) resulting in "0.0000-0" instead of "0.000000". Another issue I came across is that 0.5 rounds to 0 or 1 depending on browser (worded differently: numbers are rounded off inconsistently across browsers.)

Dependencies

On modern browsers, there are no dependencies. But to run sprintf on older browsers you’ll need to patch the Number and String objects. Number needs toFixed, toExponential and toPrecision methods, while String needs a replace method capable of using functions in the replacement parameter.

cells: function(row) {
  if(row == undefined) return this.tab...
  return $(row).getElementsBySelector(...
}

Let’s get this straight: undefined is not a reserved word. It’s safer and more logical to make the comparison to null:

cells: function(row) {
  if(row == null) return this.tab...
  return $(row).getElementsBySelector(...
}

As null is a reserved word (and it’s quicker to type) I’d expect the Prototype community to favour it.

Note: assuming undefined hasn’t been redefined, the two code fragments are functionally identical. i.e. the equals operator (==) treats null and the primitive value undefined exactly the same.

Server-side validation

It’s a golden-rule of web-development that you never depend on client-side validation. Users can turn JavaScript off, and hackers can send any data they like at your servers. So, the first thing you have to decide is what data is acceptable to your server. For numbers on the server, are you planning on storing them in a database or performing calculations with them? In either case, what format do the numbers need to be in: integers? decimals? Are you going to manually trim white-space from the number, are you going to allow negative numbers?

(it’s tempting to make the server-side validation anally-retentive, not accepting anything except a strict sequence of decimal numbers. I’d suggest that you at least accept (and remove) white-space around submitted numeric values. This will avoid frustrating JavaScript-disabled users in the case where a form-field has some trailing white-space in it – impossible to see, and annoying to find and remove after receiving an “invalid input” error.)

Client-side validation

Once you’ve decided on and coded-up your server-side validation, it’s time to think about client-side validation. Remember, the point of client-side validation is to avoid unnecessary round-trips to the server. If you can determine that user-input on the client isn’t going to be acceptable to the server, don’t even bother sending it; instead, display informative and instructive messages to the user indicating which input you don’t like, why, and what type of input you want from them.

We need an example to work with. I’m feeling unimaginative, so I’m going to use the stock order-form example. Let’s suppose we have a quantity field that (for arbitrary business reasons) we will only accept with an integer from 0 – 100. One naïve approach to validation may be:

var quantity = document.orderForm.quantity.value;
if (quantity < 0 || quantity > 100) {
  // inform user of invalid input
}

Remember, form-field values are always strings, so the code above is relying on automatic type-conversion from strings to numbers using the < and > operators. Unfortunately, if the user doesn’t input anything (quantity === ""), this would be treated exactly the same as if they’d entered 0; and the quantity would pass our input validation.

I just mentioned that the validation would pass for an empty-string; in fact, validation would pass for any input consisting solely of white-space. That’s due to the JavaScript behaviour: "\s*" < 0 is false and "\s*" == 0 is true (where I’ve used \s* to mean ‘optional white-space’.)

Considering parseInt

So, we don’t want white-space to be treated as 0. Fortunately (for now), parseInt (and parseFloat) will return NaN for white-space input. We could try to improve our code like this:

var quantity = parseInt(document.orderForm.quantity.value);
if (isNaN(quantity) || quantity < 0 || quantity > 100) {
  // inform user of invalid input
} else {
  // assume everything's hunky-dory?
}

But, oh dear lord, what a can-of-worms we’ve just opened: parseInt accepts numbers in octal and hexadecimal as well as base-10, and it’s unlikely that we want to send octal or hexadecimal numbers to our server. The sensible thing to do would seem to be to specify that we want to parse base-10 numbers using parseInt(quantity, 10).

This just makes things worse. Where we would have had parseInt("0xFF") returning 255 (and failing validation), we now have parseInt("0xFF", 10) returning 0 which passes our validation. In other words, our client-side code has passed and we’re going to send the server “0xFF” as the quantity. Hopefully your server-side code would validate this and return an error, but it feels like a waste of a round-trip.

There are also problems with floating-point numbers and scientific notation. i.e. parseInt(“2.34″, 10) returns 2 as does parseInt(“2e04″, 10), but either of these inputs could cause problems on the server (“2e04″ is scientific notation for 20000, but parseInt(x, 10) stops parsing as soon as it reads a non-digit character.)

And then there’s the just-plain-strange input: parseInt("3 bikinis", 10) returns 3. What are you going to do with "3 bikinis" on the server? It’s crazy-talk.

Clearly, parseInt is not enough on it’s own.

Regular Expressions

We’re talking about a quantity field, where we want a non-negative integer. A simple-regular expression to check for a sequence of decimal digits is: /\d+/. That still doesn’t help us avoid any trailing characters, so we need to pin it down using the ^ and $ markers. Remembering that the user can’t see white-space, we’ll show some tolerance by allowing leading and trailing white-space round the character (usually, you’d trim the field before validating, but I’m just adding some optional white-space to the regular-expression for now.)

var quantity = document.orderForm.quantity.value;
if (!/^\\s*\\d+\\s*$/.test(quantity) || quantity < 0 || quantity > 100) {
  // inform user of invalid input
} else {
  // do something with quantity?
}

We’re pretty happy that quantity has been entered in the right format, and we’ve used some implicit JavaScript type-conversion to check it’s in the right range (0 – 100.) But surely if we want to do some calculations on it, then we’re going to have to use parseInt or some other method of converting strings to numbers?

Unary + for type-conversion

Forget parseInt. If you know that a variable only contains digits (optionally wrapped in white-space) you can convert it to a number using a single +. Let’s assume we have a couple of hidden fields: unitPrice and shipping. We can assume these hidden fields contain numbers, and we know that the multiplication operator ‘*‘ will do automatic string-to-number conversion for us. But the binary ‘+‘ operator doesn’t (i.e. 4 + "5" equals "45" not 9.) Here’s unary + in action:

var form = document.orderForm;
var quantity = form.quantity.value;
...validation omitted...
var subtotal = form.unitPrice.value * quantity;
var total = subtotal + +form.shipping.value;

I need to be explicit about octal numbers. Although parseInt will (by default) parse octal, hexadecimal and base-10; when it comes to operators, octal is ignored. In other words, "0xff" == 255 is true, but "010" == 8 is false. Similarly +"0xff" is 255 but +"010" is 10.

Unary + has a lot going for it, and if you’re using prototype this should appeal:

var total = ($F('unitPrice') * $F('quantity')) + +$F('shipping');

(though I’ll never understand why they chose to use $F instead of $V. ‘F’ for field, ‘V’ for value, surely? But I digress)

Summary

I set-out to briefly demonstrate how nice and compact unary + is, but managed to get side-tracked once again. The original summary would have been “+ rocks! parseInt sucks”, but instead, we’ve got:

• Beware of white-space
• Know your number formats
• Unary +
• Use regular-expressions to check user-input matches a required format
• Show some lenience

Coming Soon…

The next two articles are very likely to touch on getComputedStyle and CSS’s !important modifier. The first should be quite short (but I tend to waffle, so it’ll probably end up long), and I need to work on some examples or illustrations for the second one. After that, I’m not sure. I’ve got some ridiculous code for creating PNGs in JavaScript, so I’ll probably give that an outing at some point.

Thanks for reading.