jQuery Plugin: Paste Events

I’ve been using a lot of jQuery lately to build web interfaces that react to user input. Part of the application I’m building makes heavy use of the keyup event to update a live preview of the app when a user enters text in an input element. This was sufficient for manually typing text and pasting from the clipboard using the standard keyboard shortcut (something I have always done), but today I was reminded that there are people out there who still cut & paste using their mouse and the built-in browser menus.

So this is when I turned to jQuery’s awesome paste event! Except it didn’t work as I expected it to. The event is fired before the input element’s value gets updated, presumably to allow the developer to do some validation of the current value and react accordingly. A simple timeout is all that’s needed to get the value pasted in the input. I needed to listen for these paste events in quite a few places and react to them after the input had been updated, so I wrote this awesome little plugin to make life easier:

$.fn.pasteEvents = function( delay ) {
    if (delay == undefined) delay = 20;
    return $(this).each(function() {
        var $el = $(this);
        $el.on("paste", function() {
            $el.trigger("prepaste");
            setTimeout(function() { $el.trigger("postpaste"); }, delay);
        });
    });
};

What does it do? Calling $.pasteEvents() on an element adds a tiny event handler that triggers a prepaste event before and postpaste event after a paste event occurs, making the task of handling paste events so much easier.

Now reacting to paste events is as simple as:

$("#some-element").on("postpaste", function() { 
    // do something
}).pasteEvents();

My First E-3 Visa

Two months ago I accepted a job offer at a software company in Palo Alto and since then I’ve been going through all the necessary steps of obtaining a visa so I can work in the U.S. I’m happy to say that my visa was approved this morning during my interview in Vancouver and I’d like to share my experience to add to the other helpful insights on this topic.

Continue reading

Slow Virtual Hosts in OS X Lion

Back in March I made the switch from Windows to OS X when I purchased my 13″ Macbook Pro. Since then I’ve trying to configure my ideal development environment, which has mostly meant deciding on the code editor that best suits my needs and workflow. I’ve been using XAMPP for my LAMP stack and so far things have been great. That is, until I upgraded to Lion a few months ago.

After making the upgrade to OS X 10.7 I soon noticed some of the websites running on my local server become incredibly slow. The most annoying part was trying to access phpMyAdmin to browse tables and run SQL queries. Sometimes accessing these local sites would be instant and other times they would hang for a few seconds before loading.

I turned to Google and searched for things such as “OS X Lion Apache slow after upgrade” and “Lion lookup slow”, but ever found useless posts related to people with slow internet connections not being able to download the Lion upgrade installer. At one point I tried reinstalling XAMPP and after that failed I started to consider the idea of reinstalling a clean copy of Lion. Thankfully I never did because today I discovered this Stack Overflow post after googling “Local DLS slow OS X Lion”.

The Problem

Basically Lion handles .local TLDs differently to Snow Leopard. Whenever I would try to access my phpMyAdmin installation at http://xampp.local/phpMyAdmin, Lion would take a ridiculously long time to resolve the host and it probably has something to do with the Multicast DNS feature of Bonjour. You can read more about Bonjour and the .local TLD here.

The Solution

The easiest solution is to simply stop using the .local TLD for your virtual hostnames. You could use an alternate TLD such as “.dev”, but further reading has hinted that inventing your own TLDs is a bad idea altogether due to potential naming conflicts. The recommended solutions that prevent these naming conflicts are overkill for my small development environment, so I’ve simply chosen to go against the advice and use a different TLD for my virtual hosts.