Alfa Jango Blog Engineering, Software, and Entrepreneurship

Archive for the ‘Web’ Category

jQuery EasyTabs v2.3 released – AJAX tabs and more

Thursday, September 15th, 2011

The jQuery EasyTabs plugin has recently hit v2.3 (well, v2.3.3 by the time I got this published). New for EasyTabs this release:

See demos for each new feature below

AJAX tab content

It’s been a long-time coming, and it’s finally here. EasyTabs now supports loading content into panels via ajax.

EasyTabs has always placed emphasis on semantic, meaningful markup. Traditionally, markup for a tab/panel pair would look something like this:

<a href="#panel-1" class="tabs">I'm a tab</a>
<div id="panel-1">Panel content</div>

Notice that in the above example, if JavaScript is disabled, we’re left with a normal anchor and anchor link in the page, which browsers understand by default.

(more…)

New ajax:aborted Rails jQuery UJS Hooks

Tuesday, May 3rd, 2011

In my last article, Rails jQuery UJS: Now Interactive, I talked about my push to make Rails jQuery UJS (aka jquery-ujs) more interactive and easier to customize and extend with third-party plugins. Along those same goals, let’s discuss another recent change: ajax:aborted hooks.

There are now two scenarios where remote forms will not be submitted, and the AJAX submission will instead be aborted. When this happens, jquery-ujs now publishes hooks, to which we can bind handler functions to gracefully handle these situations.

Let’s take a look at each of these scenarios and how we can utilize the event hooks.

Scenario Hook name
blank required fields ajax:aborted:required
non-blank file inputs ajax:aborted:file

Required fields

(more…)

Rails jQuery UJS: Now Interactive

Friday, April 22nd, 2011

The Rails jQuery UJS adapter (aka jquery-ujs) has undergone some major renovations over the past few weeks. This particular change is one I’m very excited about, as I’ve been wanting to do this for a while. Without further ado, jquery-ujs is now InteractiveTM.

What do I mean by “interactive”? Well, we can now plug into every facet of jquery-ujs, binding to custom events, and even customizing internal functions, without hacking or monkey-patching the rails.js file itself.

We’ll start with a brief explanation of the change and then dive into a few examples.

Feel free to bypass my blabbering and check out the the commit.

Closure style

Previously, rails.js was one big closure.

Before:

(function($) {
  ...
  function fire(obj, name, data) {
    var event = $.Event(name);
    obj.trigger(event, data);
    return event.result !== false;
  }
  ...
})( jQuery );

// cannot access fire() function here

This closure design had many advantages. However, the biggest advantage, in this case, happened to be the biggest disadvantage as well: everything inside was self-contained and inaccessible by the outside world.

So, what if we like most of what jquery-ujs does for us, but just want to modify one little function? Before, we’d have to open rails.js in our editor and start hacking away. But no more!

Object literal style

(more…)

Rails 3 Remote Links and Forms Part 2: Data-type (with jQuery)

Tuesday, January 18th, 2011

Continued from Rails 3 Remote Links and Forms: A Definitive Guide.

Since writing the Rails 3 Remote Links & Forms Definitive Guide, one question keeps coming up:

How can we make our remote links and forms retrieve JS.ERB, instead of an HTML partial?

In the last article, we requested an HTML partial to be inserted into the page by our AJAX callbacks. But what if we want JavaScript to be executed? Or JSON or XML to be parsed? Or plain text to be displayed?

Spoiler Alert: this article concludes with a complete working example using js.erb.

Equal parts Rails & jQuery

First, we must understand the :remote => true process in Rails 3. It’s equal parts Rails and jQuery magic. But don’t worry, it’s very little magic, bundled into a 4-step process:

  1. Rails tells jQuery, “Hey, bind your ajaxy goodness to this sweet little link/form,” with the :remote => true option.
  2. jQuery hi-jacks the element’s click/submit event and binds it to the .ajax() method. Now that element submits via AJAX instead of loading a new page in the browser.
  3. Rails receives the AJAX web request when the element is clicked/submitted and responds with some content.
  4. jQuery receives the response content with the .ajax() method that hi-jacked our element, and provides callbacks for us to handle the response in the page.

In this article, we’re exploring the different ways we can specify the format of the AJAX response and handle it accordingly, which actually spans all 4 steps above.

(more…)

Track jQuery AJAX Requests in Google Analytics

Thursday, January 6th, 2011

There is an easy way to track all jQuery AJAX requests in an application. This method could really be used to log our AJAX requests however we wish, but this particular example will log requests to Google Analytics.

The code

This code will automatically log all jQuery AJAX requests in our application, including those using $.ajax(), $.get(), or $.post() (and .load() too).

This will also work for any jQuery plugins using AJAX requests (e.g. lightbox plugins, etc.), as well as for all Rails 3 remote links and forms (provided we’re using the jQuery UJS driver).

In the page layout or in an included js file, we add the following JavaScript:

(more…)

Disable Rails 3 Remote Links After Click (using jQuery)

Thursday, December 23rd, 2010

I’ve frequently come across the need to disable remote AJAX links in Rails 3 after the first time they are clicked.

The typical scenario is that we have a link that fetches content from the server and loads it into the page. The problem is that after the first time the user clicks it, and the content is loaded into the page, we don’t want to keep fetching the same content from the server and re-loading it into the page if the user clicks it again.

The ideal solution

Ideally, we could easily just unbind the click.rails event binding to disable the links after we click them. In fact, that’s why I added the .rails namespace to the event bindings in rails.js in the first place.

Unfortunately, jQuery is not able to unbind (aka .die()) .live() bindings for specific elements in this way. See the Problem with .die() section in Exploring jQuery .live() and .die().

The good news is that I’ve rewritten the .die() method in jQuery to go along with the namespacing change to rails.js, so that we can do this. And it looks like the jQuery core team is planning to pull my rewrite into jQuery 1.5 (see discussion).

But until then we’ll have to make do with…

(more…)

Rails 3 Remote Links and Forms:
A Definitive Guide

Thursday, October 28th, 2010

Also see Rails 3 Remote Links and Forms Part 2: Data-type (with jQuery).

Spoiler Alert: If you like magic, stop reading. The Rails 3 UJS driver (rails.js), which powers the remote links, forms, and inputs, is not very magical when you know how it works.

This article uses the jQuery UJS driver, though the Prototype UJS driver does the same thing. UJS, by the way, stands for “Unobtrusive JavaScript”.

If you have any experience with jQuery, take a few minutes to check out the rails.js source. It’s pretty straight forward, and only 147 lines as of this writing. I’ll be here waiting to answer your questions when you get back.


What rails.js does

  1. It finds remote links, forms, and inputs, and overrides their click events to submit to the server via AJAX.
  2. It triggers six javascript events to which you can bind callbacks to work with and manipulate the AJAX response.
  3. It handles the AJAX response from the server

What rails.js does NOT do

Notice that last bit is struck-through. This seems to be the greatest source of confusion when starting with the new Rails 3 remote functionality. Thanks to habits engrained by Rails 2′s link_to_remote and remote_form_for, we expect that Rails 3 would also handle the AJAX response for our remote links and forms. But it doesn’t; it leaves that for you.

Rails will take your luggage up to your room, but it won’t unpack your bags for you. This is by design; why would you want the bellhop going through your stuff? Also, the actual handling of the data is largely unique to each element, and depends on the data you’re working with in each case. So Rails leaves that part up to you. We’ll come back to this.

The role of HTML5

You’ve likely heard that Rails 3 uses HTML5. That’s true, but the actual role that HTML5 plays may be simpler than you suspect.

(more…)

Pure-CSS Emoticons WordPress Plugin Released

Wednesday, September 22nd, 2010

I’ll keep this post short and sweet. My good friend, Anthony Montalbano, has released a WordPress plugin for our CSSEmoticons jQuery plugin. Now you can use pure-CSS emoticons in your blog or WordPress site simply by installing and activating the WordPress plugin.

The WP plugin currently has options for you to apply “emoticonization” to your posts, the comments, or both.

Also, since the CSSEmoticons jQuery plugin doesn’t currently work with Internet Explorer, the WP plugin automatically reverts to WordPress’s built-in emoticon image-replacement for Internet Explorer.

Be sure to check it out and try it on your blog if you’re cool enough B-) . We’re already using it on this one, and we <3 our new plugin.

A Practical Application for Pure-CSS Icons: Emoticons

Monday, September 13th, 2010

CSS3 is great and there is no shortage of amazing showcases highlighting what you can do with a little CSS3 and a lot of time. One popular theme for showing off the capabilities of CSS3 has been creating pure-CSS icons that you’d swear are images (like these or these).

Why other pure-CSS icons are not practical

Complex pure-CSS icons are not practical for use in production websites. They are difficult to maintain and are often only possible with an un-semantic mess of markup. Not to mention, we already have the perfect tool for graphic representations: images. (For more on this, see Faruk Ateş’s post on the subject.)

Why pure-CSS emoticons ARE practical

Think about it, the great thing about emoticons is that they are textual representations that are inherently and immediately recognizable as faces expressing the emotions they represent.

Traditionally, if you wanted to display emoticons graphically on a web page, you used a script (typically javascript) to find and replace text-emoticons with small smiley-faced images that correspond to each emoticon. But if textual emoticons already resemble these faces, isn’t it overkill to completely replace them with images that resemble these faces just slightly more?

Further, inserting images now breaks the ability for visitors to copy and paste the text elsewhere. Well, technically they can still copy and paste, but it completely skips the emoticon images, instead of allowing them to simply copy the original text as written. I.e. The following text:

gets copied and pasted as this:

That makes sense  I’ll update the post.

Notice, the smiley is omitted, potentially altering the context of the original text.

UPDATE: Many browsers will copy the alt attribute text of the image if it is set properly. However, webkit-based browsers, such as Safari and Chrome, do not do this. Thanks for the tip, Faruk Ateş (via email).

Enter our new jQuery plugin / stylesheet. It keeps the text emoticons completely intact, and just gives them a little anthropomorphic nudge with CSS. Now, using pure-CSS emoticons, this:

gets copied and pasted as this:

That makes sense :-) I’ll update the post.

Benefits of pure-CSS emoticons

There are several reasons to use pure-CSS emoticons over the traditional image-replacement method:

  • Keeps text markup semantic (plugin only wraps textual emoticons in a single <span> element).
  • Retains original text, as typed, for copy/paste and page indexing.
  • Automatically sizes to fit the text. No need for multiple emoticon image sets of varying sizes.
  • Does not break the line-height of paragraphs like most of the image-replacement methods.

Check it out

Without further ado, we proudly present the CSS Emoticons jQuery plugin

“W” is for Facebook
(in Google’s Instant Search)

Friday, September 10th, 2010

Google Instant Search is here, and over the last couple days there has been much hurrah about the sites that Google now loads directly into the results as you type, even after you’ve only typed in a single letter. Fast Company and Mashable have written about it. And before them, the Huffington Post wrote about it. And eight months before that, this little blog wrote about it. (By the way, the Huffington Post was nice enough to link back to us, so hats off to them!)

If you’re interested, check out Google One-letter Suggestions, where we analyzed the first 10 results for each letter (unlike these other publications who only look at the first result) and found some interesting trends back in December.

You see, these instant suggestions have been around for the better part of the year, before Google introduced Instant Search. Instead of loading the pages instantly as you typed though, it merely suggested search terms as you typed. In a way, Instant Search is actually the second step in a gradual release. The first step (the search term suggestions) meant you didn’t have to finish typing your search query, and the second step takes it just one step further, eliminating the need to hit ‘Enter’.

But what I really want to bring up is something I can’t believe none of the other major publications picked up on. This is the thing that I found the most interesting out of the entire analysis. If you type the letter “w” into Google, one of your top ten search suggestions is Facebook! Facebook? Yes, apparently enough people type “www.facebook.com” into Google that Facebook is a top-ten result for the letter “w”.

(more…)

Page 1 of 212