But all of those solutions fall short in one way or another.

So I decided to write a jQuery plugin that would turn a plain old text input into an IP address form widget that operates like one you’d find in your operating system.

The plugin parses out existing text in the input (in case the user is editing an existing IP) and creates 4 new text inputs. As the user types the IP address, the cursor jumps to the next box. But if I left it there, it would be pretty lame, right?

The plugin also adds event handlers to the inputs to limit keys. There are also event handlers that will allow right and left arrows to jump between inputs and backspace will continue across inputs as well.

I had to write another plugin to get the cursor handling working correctly, so it’s required for the IP address plugin.

As the user is typing, if all 4 IP octets have a value, the original IP address will be repopulated with the IP address from the widget.

Check out the demo or download the scripts and styles.

What does that mean? I’m not entirely sure.

(Demo)

Here’s the goal…

I want to be easily able to add a function to the undo queue.  When I press the undo key combination, that function will run again and it will be placed in the redo queue:

This is really not ideal.  While some functions toggle correctly, not all do.

What I really is to be able to define a function for undo and a function for redo:

I really think I can get away with both of them.

Check out the demo and let me know what you think. (Hint: Open the Firebug console)

The goal for this plugin was to create a event handler for text and page zooming in a browser window.  While this can’t be accomplished entirely without some better event support in the browsers, I can watch for keyboard and mouse shortcuts that result in zooming.

This plugin itself doesn’t care if you zoomed in or out. It just runs the callback function when you zoom. Maybe at a later point, I’ll add that feature.

Without any further ado, here’s the plugin code:

Because we’re dealing with browser implementations of keyboard shortcuts, I decided to use jQuery.browser (which uses navigator.useragent) to deal with the browsers individually. Much to my surprise (and delight), Internet Explorer and Firefox handle zooming identically.

Lines 2 – 30 deal with zooming through keyboard shortcuts. The character codes are as follows:
42: * (numpad)
43: + (numpad)
45: – (numpad)
48: 0 (numpad in FF and IE)
96: 0
107: + (numpad in FF and IE)
109: – (numpad in FF and IE)
187: +
189: -

Lines 32-38 deal with scrollwheel zooming in Firefox and IE. Opera doesn’t run the callback function for the scrollwheel when the CTRL key is pressed (which is how scrollwheel zooming is done in Opera). Safari 2 (which is what I have) doesn’t support scrollwheel zooming at all.

Further testing needs to be done in Safari 3, but this plugin works pretty well as is. Here’s how you’d use it:

Here’s the download and the demo.

UPDATE: You can find the latest version of the plugin here.

You could then assign a handler like so:

So much more needs to be added to this and I’m not even sure I’m headed the right direction. For example, I can address another way of zooming (CTRL-scrollwheel), but I doubt I can capture use of the menu in the browser. Also, I could probably assign different keys to zoom. I might have to come up with a different solution entirely.

Pass in a SQL date and the function trims leading zeros and returns a reformatted date.

Crazy Europeans may want to change the replace regex with ‘$3/$2/$1′.

Great concept, right? No need to tell it where to send the data or what fields to send, since the form already contains that info. It’s mostly unobtrusive, so any browser that doesn’t have JS enabled would still be able to submit.

So my immediate response was, “Very cool. I’m sure a jQuery plugin either exists or could be created pretty easily to handle that.”

I built the following plugin in maybe 30 minutes, and had it tested in another 15.

There are some of you that are wondering, “Why is this necessary? I can write my own jQuery.ajax() code every time.” Yep, and that’s part the problem I’m trying to solve. The plugin is a shortcut for most of the jQuery.ajax() code you’d normally write and it makes unobtrusive form submission dead simple:

The function takes one parameter, an object that extends the jQuery.ajax method.

Here’s a demo and the download.

2008-09-23: Updated window.location to window.location.href (Thanks Samori)

I ran into this issue recently and wrote some cool little handlers for objects. The following methods can be used to iterate through an array manually. I wrote them for Actionscript, but they certainly work for Javascript – although I’d suggest one small modification (shown later).

Let’s get to the code.

In each of the “for in” loops below, I make sure to exclude any prototyped methods. If I don’t, they’ll show up in the loop – which can be pretty bad.

The ‘first’ method starts looping through the array, but returns the first item in the object as soon as it gets to it.

The ‘last’ method loops through the object, storing the current item in a variable. When it finishes the loop, it returns that variable – the last item in the object.

The ‘previous’ method loops through the object looking for the ’subject’ variable. If it matches the variable with the current item, it returns the previous item – set after the if statement below (in the previous time through the loop). If it never matches the variable or the previous item is never set, it will return the last item of the object.

The ‘next’ method loops through the object looking for the ’subject’ variable, as well. However, when it matches the variable it sets a ‘found’ flag. The next time through the loop, the current item will be returned. If it never matches the variable or the matched item is the last in the object, the first item will be returned.

So let’s do some examples. My test object has 3 items – one of which contains an array:

Simple as that.

The one change that I would recommend looking into for Javascript is better checking for the “for in” loops.

Instead of:

The hasOwnProperty property is recommended:

First, just a quick note about this event handler. You won’t find it in any W3C spec because it just isn’t there. Why? I don’t know, but I do know that it’s supported by Firefox and Internet Explorer 6/7 – which is ~90% of the browser usage and possibly more (read: I need to fire up my Mac and test it). Apparently, this event handler has been around for a long time – see this brief e-mail exchange on the HTML users group.

Okay, let’s get started. Recently, I was working with some external data where I didn’t know whether I would have an image with each item the data or not. This is a simple problem that can be solved using server side code (since the data feed needed to be parsed into a database table anyway). However, I found that the links to some of the images returned 404 errors. I’m not a usability expert, but have broken images looks pretty bad, even if you use alt attributes. The onerror event handler is perfect for this situation. Here’s how it works:

You assign the attribute to the image tag with some sort of error handler:

Then, create your error handler function. You could replace the image with a “No image” image (like I did):

Or you could just remove the image altogether:

If you want to read more about using onerror with <body> tags, MDC has some documentation.

That having been said, there are some applications where I cannot use a Javascript library and I need to use the (longer) Javascript methods. There’s nothing wrong with this – in fact, I find that I always learn something new. Such was the case today.

I decided that I would attach some events using the addEventListener function. I had always either used the older method of attaching events or some helper library. So I checked out the spec on MDC and saw that Internet Explorer had its own version of this function called attachEvent. I hate how Internet Explorer does things like this. There are standards for a reason, you know.

Anyway, I wrote a simple function that would apply the event, but it was not working in Internet Explorer. So I started debugging the issue.

“Is the event being attached?” – Yes

Is the event being attached to the right object?” – Yes

Can I alert some text in the event function?” – Yes… odd.

Here’s my function:

It turns out that Internet Explorer doesn’t pass the ‘this’ object to the event function. ‘this’ is this instance should be the object that had the event attached.

It’s no shock to people that know me that I hate Internet Explorer. I even sell T-shirts declaring that fact. But this is just stupid.

Why did Microsoft have to implement their own version of addEventListener? Why did they have to implement it so horribly that it doesn’t return ‘this’?

I ended up writing a workaround that just used the older method of applying the event to the object. Here’s the finished version:

It’s really just adding insult to injury, since the only reason I had to write this function is because Internet Explorer doesn’t handle the CSS :hover pseudo-class for DIV elements.

Anyone want a T-shirt?

function addMethod(object, name, fn){
  var old = object[ name ];
  object[ name ] = function(){
    if ( fn.length == arguments.length )
      return fn.apply( this, arguments );
    else if ( typeof old == 'function' )
      return old.apply( this, arguments );
  };
}

Here’s how you could use it to extend the User object that we created earlier.

addMethod(User.prototype, "find", function(){
  // Find all users...
});
addMethod(User.prototype, "find", function(name){
  // Find a user by name
});
addMethod(User.prototype, "find", function(first, last){
  // Find a user by first and last name
});

You can read more from John’s blog here.