Ajax is a wonderful technology that is heavily used in many places nowdays. Ajax is run in the browser using javascript to call a URL, and usually receive data back. One of the key restrictions of using Ajax to get data from a remote URL is that you cannot make cross-domain calls. This meaning, you cannot make an ajax call to domain1.com from domain2.com because of browser security restrictions. The workaround, is to make the cross domain ajax calls from your web server rather than the browser, and all is fine!

That was, until the introduction of JSON, and more importantly JSONP which allows you to make ajax calls to 3rd party domains from within the browser itself. What this means for you is that you can get data from JSONP supported APIs from within the browser itself, rather than telling your web server to do it for you.

This is also important for Twitter API usage. One of the key restrictions with the Twitter API is that any client IP address can only make x number of API calls per hour. If you’re making these API calls from your web server (which obviously only a static IP address), you could quickly use up your hourly allocation on a busy site. Twitter does allow you to “whitelist” your web application to give you a better hourly rate, but here’s a better way:

Use the clients, ie your users, to make the API calls from their browsers.

Admittedly, my example below is for any API calls that do not require authentication, however what it does enable you to do is to empower your user to make Twitter API calls in the browser using jQuery. So without further ado, here’s the code snippet:

$.getJSON("http://twitter.com/statuses/user_timeline.json?screen_name=SteveReynolds&callback=?",

function(data){

$.each(data, function(i,item){
$("#tweets").append(item.text + "<BR/>");

});

});

What the code above assumes is that you have a <div id=”tweets”> or something where you can append the results, in this case the object in the JSON response “item.text” which is the tweet itself. You could for example, get “item.user.name” which would return the username for each tweet (which is useless as you know it’s all my tweets ) – but you get the idea. You also need to make sure you have previously called the jQuery library.

The other important factor of the code above is the URL we are using to call Twitter. We have appended “&callback=?” onto the end of it. This is to allow the jQuery call to pass the returned data to a callback function, which in this case is simply called “data” for the returned data, and “function()” for the callback.

Download the code here.

So, that’s it. It really is that simple. In my next tutorial I will show you how to do the above, but ajax it back to your server and save it to your database – in effect getting your users to do a lot of the hard work for you in the browser, and simply sending back the relevant results to your database.

Back in the early part of this year I posted an article around how to get MySQL data out of the database and into a web page via jQuery and Ajax. The tutorial was okay, but I made some rookie mistakes – specifically around the creation of XML data with PHP – This time, I hope to rectify that!

So this article will focus on getting data from a database using PHP, converting that to an XML document, and reading that XML in through jQuery via Ajax calls. Seems complex, but is in fact, very easy.

Database Design

This tutorial assumes you know how to connect to your database. It also assumes that you have a table setup called “people” with 3 columns: “title”, “firstname” and “surname”. Please enter some data into this table as it will be required.

The XML structure

So, the point of this tutorial is to read some XML with an Ajax call from jQuery, therefore we need to structure our data correctly. Here is an example of the structure our XML document will generate:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<people>
<person>
<firstname title="Mr">Steve</firstname>
<surname>Reynolds</surname>
</person>
<person>
<firstname title="Mr">David</firstname>
<surname>Grohl</surname>
</person>
</people>

I won’t go into anymore details other than that is what our PHP script will generate for us for each row entry in the database.

The PHP

First up, we’ll get the data from the database, and then iterate through each row result to generate the XML for that particular entry. We’ll do that by using the PHP function DOMDocument() which creates an XML document for us, and also allows us to add nodes and children to the XML on the fly.

$query = "SELECT title,firstname,surname FROM people";
$result = mysql_query($query);

$doc = new DomDocument('1.0');

// create root node
$root = $doc->createElement('people');
$root = $doc->appendChild($root);

while($array = mysql_fetch_array($result)) {

	// add node for each row
	$occ = $doc->createElement('person');
	$occ = $root->appendChild($occ);

	$child = $doc->createElement('firstname');
	$child = $occ->appendChild($child);
	$child->setAttribute('title', $array['title']);
	$value = $doc->createTextNode($array['firstname']);
	$value = $child->appendChild($value);

	$child = $doc->createElement('surname');
	$child = $occ->appendChild($child);
	$value = $doc->createTextNode($array['surname']);
	$value = $child->appendChild($value);

}

Next up we need to form that into an XML file. The way we do this is tell the PHP file to save the XML document with the saveXML() function, get the PHP script to respond with an XML type header, therefore anything that is echoed out will be interpreted by the browser as XML. So after the code above, add this:

$xml_string = $doc->saveXML();

header('Content-Type: application/xml; charset=ISO-8859-1');

echo $xml_string;

So, the header part tells the browser that this is an XML content type, and the rest is simply echoing out the XML data structure as mentioned previously.

Hopefully now, when you run that PHP script you should return a valid XML document…

Ajax with jQuery

The last piece to this puzzle is getting that XML data into an HTML page using jQuery and ajax. Again, it’s pretty easy to do, here is the basic HTML structure I am using for this tutorial:

<html>
<head>
<title>The HTML</title>
<script type="text/javascript" src="jquery-1.3.1.min.js"></script>
<script type="text/javascript" src="thejs.js"></script>
</head>
<body>
<div id="container"></div>
<input type="submit" id="getData" name="getData" value="Get Data!" />
</body>
</html>

You need to obviously include the jQuery library, I am also including an external javascript file for our jQuery code. So go ahead and create a javascript file called thejs.js and put the code below into it:

$(document).ready(function() {
$("#getData").click(function(){
var data = "";
$.get("thephp.php", function(theXML){
$('person',theXML).each(function(i){

var title = $(this).find("firstname").attr("title");
var firstname = $(this).find("firstname").text();
var surname = $(this).find("surname").text();

data = data + title + " " + firstname + " " + surname + "<br>";
});
$("#container").html(data);
});
});
});

So this code is firstly wiring up a click event on a button, and then making a GET Ajax call to the PHP script we made earlier. Once it receives some XML data it iterates through each “person” node.

Notice, I am returning two different data sources from the XML, the data in between the <firstname> and <surname> tags, as well as also returning the data for an XML node attribute, in this case “title”. This doesn’t really make much sense in this context, but what it does show you is how you can access attribute information with the function.

Download

Download

So that’s it! You can see a working demo of this here. Download all the sourcecode by clicking the box icon on the left hand side. The code is fully working, you just need to add your database connection code to the PHP script. Feel free to leave feedback and comments in the section below!

Tools to help you learn…

Learning jQuery 1.3	PHP MySQL Development	jQuery UI 1.6

So I thought I would have a whizz at creating a custom 404 error message page, seeing as they’re so dull! What better way to do this, than with some sexy jQuery UI animations, and a snipsy bit of jQuery? This tutorial isn’t limited to 404 error pages, you can use this animation technique anywhere. Here’s the premise – a 404 that’s breaking, the page is literally cracking into bits:

Click to see my cracking demo

You’ve got to check it out above! You like? Here is how I did it.

HTML & CSS

First off I built a basic HTML structure – this obviously has key parts missing, but for the sake of the demo this is what we’ve got:

<html>
	<head>
		<title>404 - File Not Found - Reynoldsftw.com</title>

		<script src="js/jquery-1.3.2.min.js"></script>
		<script src="js/jquery-ui-1.7.2.custom.min.js"></script>
		<script src="js/jquery-background.js"></script>
		<script src="js/controller.js"></script> 

		<LINK href="css/style.css" rel="stylesheet" type="text/css">
	</head>
	<body>
	<div id="error_code">404</div>
	<div id="error_status">File Not Found</div>
	<div id="error_message">We're sorry you are seeing this page, please don't break the site again!</div>

	<div id="crack"></div>
	<div id="crack_overlay"></div>
	</body>
</html>

Some DIVS for the text content, and also a couple of empty DIVs that will hold two images. One being the crack, the second being an overlay .png file which we will animate over the top. Here’s the CSS for those two image DIVS:

#crack
{
	z-index: 1;
	position: absolute;
	width: 200px;
	height: 600px;
	background-image: url(../images/crack.png);
	left: 520px;
	top: 0px;
}

#crack_overlay
{
	z-index: 1000;
	position: absolute;
	width: 200px;
	height: 600px;
	background-image: url(../images/crack_over.png);
	background-position: 0px -1100px;
	left: 520px;
	top: 0px;
}

A couple of things to note – the overlay image is extremely large in height, therefore I am positioning it in the DIV so that in that position, the crack image/DIV underneath it cannot be seen (background-position-y: -1100px;). Both DIVs are absolutely positioned, as well as the overlay having a z-index higher than that of the image/DIV underneath. Okay, let’s “crack” on…

jQuery and jQuery UI

Next we have the jQuery UI and jQuery code. I’ve chosen to use the “shake”, “bounce” and “pulsate” jQuery UI effects, setting their options quite tightly so that the movements made are very minimal – giving the wall shaking, earthquakey effect. I’ve also set some timers to randomly shake various elements, as well as re-position the overlay so that more and more of the crack is revealed.

var coord = -1125;

$(document).ready(function() {

	setTimeout("shake()", 2000);
});

function reveal()
{
	setTimeout("moreCrack(coord)", 200);
}

function shake()
{
	coord = coord + 50;
	if(coord < -125)
	{
		$("#crack").effect("shake", {distance: 1}, 40, reveal);
		$("#error_code").effect("bounce", {distance: 5}, 50);
		$("#error_status").effect("pulsate", {times: 2}, 50);
	} else {

		$("#crack_overlay").hide();	

	}
}

function randomXToY(minVal,maxVal,floatVal)
{
  var randVal = minVal+(Math.random()*(maxVal-minVal));
  return typeof floatVal=='undefined'?Math.round(randVal):randVal.toFixed(floatVal);
}

function moreCrack(coord)
{
	$("#crack_overlay").animate({backgroundPosition:"(0 " + coord + ")"});
	setTimeout("shake()", randomXToY(3500, 5000));
}

Okay, so on the document.ready() call, I’m setting up a timer to call the shake() function. This will then call a chain of functions to shake and reveal more of the crack (moreCrack()). I then start over again, but call shake at a random interval so that it is less predictable.

Finally, the shake() function keeps an eye on the position of the overlay DIV and stops the entire thing once there is no more to reveal.

Download the solution

Download Solution

As ever, here is the code for you all bundled up. Feel free to have a play and let me know how it goes. There are a few ways looking at it at how to streamline some of the code, but I thought I’d get it out there for you all to play with for now! Probably more soon.

Anyway – click the icon to the left or download here. Please let me know if you use it, or do something even cooler with it – stick an url in the comments!

Tools to help you learn…

Learning jQuery 1.3	Amazon Kindle 2	jQuery UI 1.6

So over the past 6 months I’ve taken a look at many jQuery plugins via this website. After some time I thought it would be interesting to see out of all of the plugins I’ve looked at, which ones are getting the most interest. Well the results are in:

Here’s that list:

1. Flot : http://code.google.com/p/flot/

Flot

2. Google Charts : http://maxb.net/scripts/jgcharts/include/demo/

Google Charts

3. Sexy-Combo : http://vladimir-k.blogspot…jquery-plugin.html

Sexy-Combo Plugin Preview

4. Sparkline : http://omnipotent.net/jquery.sparkline/

Sparklines

5. (mb)ToolTip : http://pupunzi.wordpress.com/…/mbtooltip/

(mb)ToolTip

6. jqchart : http://jsgt.org/lib/jquery/…/test-use-gradient.html

jqchart

7. Raphaeljs : http://raphaeljs.com/

Raphaeljs

8. Smart Google Map: http://code.google.com/p/jquery-googlemap/

9. Alphanumeric : http://itgroup.com.ph/alphanumeric/

Alphanumeric

10. Bluff : http://bluff.jcoglan.com/

Bluff

Admittedly, a couple of these are not jQuery plugins after all, but never-the-less, they’re doing pretty well.

Observations

• Alot of these are around charting or graphing.
• Sexy-Combo is right up there, see this post for more on that. Although this should be high up due to the nature of the popularity of that article around how “Sexy Sells”
• Interestingly, the Top 10 articles where I reviewed the charting plugins isn’t way way up there in the stats Vs other Top 10s.
• I hope the developers of these plugins appreciate the traffic I am driving to their sites

So I have been trying to figure out a really simple, easy way to test the load times of my Javascript in the page, and have ended up creating a simple load time tester using jQuery called jQTester.

jQTester Displaying its results

This assumes you are using jQuery, and are running using version 1.3.1 – however it should work on most versions as the jQuery I am using is pretty lightweight.

The concept is simple – you have 2 files called start.js and end.js. Place start.js at the top, just after your <HEAD> tag, and place end.js just before </body>. Using javascript timers I am capturing the length of time between start.js loading, and the document.ready jQuery function running (when, all javascript and DOM elements should be loaded and ready to use).

Why place end.js before </body> ?

So, ideally you are placing your javascript calls at the end of the HTML document. Why? because javascript file downloads block parallel downloads in the browser. Browsers can only download 2 files per hostname at any one time, so by placing them in the <HEAD> you are in theory stopping anything else from loading within the page whilst all your javascript is being loaded. By placing them at the end of the HTML document, images etc have the chance to load first, so the perception for the user is faster load times.

So the browser will load your HTML document top to bottom. Based on the assumption that no other javascript needs to load after </body> is called, the best place to stop the timer is at that last point. That’s when the clock stops, and we assume we’re all loaded.

jQTester 0.1

So I’m not really 100% sure if this is the right way to go about this, but anyway – I’ve packaged this up as “jQTester” and am attaching version 0.1 for your perusal. It would be good to get some feedback on how I can move forward with this, as I am keen to develop a tool or plugin that can sit within the page code, rather than being a browser add-on etc.

Download jQTester 0.1

Install instructions: Use jQuery, place start.js after the <head> tag and place end.js before the </body> tag.

Add your comments below on ways to improve jQTester.

With the advent of new browsers such as Safari 4 we’re now also starting to see HTML 5. HTML 5 brings a number of things to the plate, one of the biggest things being client side databases. In addition to this, excellent JavaScript libraries such as jQuery are really making headway, making client side DOM manipulation a jingle.

JavaScript engines too are getting huge speed boosts with the latest browsers. In fact, all the latest browsers from IE to Safari are all pimping their own “awesome” and super fast JavaScript engines. There is alot of focus here, rightly so as web development quickly moves towards Rich Internet Applications (RIA).

Client-side databases

Of course, this isn’t new. Google Gears has been offering a browser plugin for server side databases for quite some time now. The trouble is, it’s a plugin. It’s not native, and requires action from the end user to install.

The great thing about it though, is that you can effectively offload a bunch of data over to the client, and get your application to query it from there, instead of your server. It also means that offline web application usage is even more of a reality as in theory, the app no longer needs to query a web server for it’s data.

Architecture and Functionality

So what does this all mean? Why should we be thinking different? Simply, this changes everything.

Think about it. You’ve got a bunch of servers, your database servers are the crux of it all, and they struggle under heavy usage due to the number of queries going on. What we should be proposing is offloading some of the database work onto the client.

What you have to remember is, a large proportion of your users are probably using a PC that is extremely powerful. Upto now, web technologies haven’t really been pushing client machines (other than the unruley flash). So why not utilise some of that power yourself, offload some of the processing of data from your servers and onto the client.

Of course, this isn’t as simple as it sounds. We have a few issues.

1. Bandwidth. We would assume that a user had the broadband capabilty to download large chunks of data quickly.
2. PC Performance. We would have to assume that all users have a fairly decent processor.
3. Browser Compatibility. None of this is mandated yet. HTML 5 is nowhere in IE8, so until it’s common place in browsers, it’s a difficult project to get underway.

That said, think of the future. Think of client side databases holding a subset of data that can be queried and manipulated in split seconds by awesome JavaScript engines within browsers. Database servers can be freed up for more important duties, even the application layer to a degree. Anyone with a major server architecture can clearly see some great wins here, if only everyone could catch up.

This post is written by Rebecca Murphey. Rebecca is a front-end architecture consultant based in Durham, N.C., specializing in jQuery development and standards-based HTML and CSS. You can read her blog or find her on Twitter @rmurphey.

I’ve been doing a lot of thinking lately about the best way to organize non-trivial jQuery features; in my article in April’s JSMag, I talk about using the object literal pattern for separating the component pieces of a feature. A second option that bears mentioning involves making use of jQuery’s custom events, and that’s what I want to talk about today.

Custom events let you structure your code such that behaviors are bound to the thing that’s being acted on, rather than the thing that triggers the action. For example, imagine a container that can be expanded or collapsed. The traditional approach would be to bind the expansion and contraction behavior to the element that triggers the behavior:

<div>
<div class="toggleElement">Open/Close</div>
<h1>Title</h1>
<div class="expandable">

Expandable content</div>
</div>
<script>
$('div.toggleElement').click(function() {
 $(this).parent().find('div.expandable').toggle();
});
</script>

An approach that uses custom events might separate the task into two parts: first, saying that the container is expandable; then, saying which element will trigger the behavior:

<div class="expandableContainer>
<div class="toggleElement">Open/Close</div>
<h1>Title</h1>
<div class="expandable">

Expandable content</div>
</div>
<script>
// say the container is expandable
$('div.expandableContainer').bind('toggleContent', function() {
 $(this).find('div.expandable').toggle();
});

// bind the expansion/contraction to the toggleElement
$('div.toggleElement').click(function() {
 $(this).parent().trigger('toggleContent');
});
</script>

As with lots of examples of new ways to do things, the custom event method is longer and perhaps a bit more confusing than the “traditional” way of handling this. However, as the number of behaviors that you can trigger grows, the more useful it becomes to have the definition of those behaviors associated with the element that the behaviors affect, rather than the element that triggers the behavior. With custom events, you can start to write code that depends less on the specific markup to which your events are bound, and more on the behaviors that certain elements are expected to exhibit. This can be especially useful when you start to define the behaviors of a widget, as you’ll see in a moment.

A quick recap of .bind() and .trigger()

Before we move forward, let’s back up for a second to make sure we have the basics covered.

jQuery offers a number of so-called convenience methods for binding behaviors, such as .click(), .mouseover(), .keyup(), etc. We’ll still use these, but it’s important to also understand the more verbose .bind() method, which needs to be used for custom events, and the generic .trigger() method, which can be used to trigger (duh) an event. We also want to understand how to take advantage of the .bind() method’s ability to store data for later use.
Here’s an example of how we could use .bind() and .trigger():

$('body').bind('foo', { 'bar' : 'bam' }, function(e) { alert(e.data.bar); });
$('body').trigger('foo'); // alerts 'bam'

For the record, you can also pass data to the .trigger() method, though this isn’t quite as pretty. Note that the first argument passed to the function handling the event will always be the event object.

$('body').bind('foo', function(e, param1, param2) { alert(param1 + ': ' + param2); });
$('body').trigger('foo', [ 'bar', 'bam' ]); // alerts 'bar: bam'

With that out of the way, let’s move on to a slightly more complex example of custom events.

An expandable, collapsible, editable, removable widget

The value of custom events becomes clearer when there are several behaviors that you need to trigger on the same element. For the sake of this post, we’re going to work on an imaginary widget that has several behaviors:

* It can be edited. Triggering the edit event loads a form for editing the widget, which is then AJAX-enabled to load the expanded widget with the new content.

* It can be deleted. Triggering the delete event removes the widget from the page, and sends a message to the server that the widget has been deleted.

* It can be expanded. Triggering the expand event the first time loads the full content of the widget from the server; triggering it again uses the already-fetched content.

* It can be collapsed. Triggering the collapse event hides the expanded content of the widget.

We’ll start with some basic HTML that represents a couple of widgets on the page:

<div class="widget" id="widget1">
<h1>Title</h1>
<div class='content'></div>
</div>
<div class="widget" id="widget2">
<h1>Title</h1>
<div class='content'></div>
</div>

Obviously these aren’t very exciting widgets, but note that they have a common class (”widget”) and unique IDs. We’ll use the class to target our event bindings; we’ll use their IDs to communicate to the back-end about which widget we’re working with when we are editing, deleting, or saving them. The back-end will be responsible for presenting us with the appropriate content or the appropriate form for editing the widget based on the ID.

Next, let’s set up the simplest custom event, delete.

var widgetScript = 'widgetManager.php';

$('div.widget').
 bind('delete', function(e, $li) {
 var $this = $(this);
 // send a message to the server to delete the widget
 $.post(
 // use the widgetScript as the URL for the post
 widgetScript, 

 // tell the widget script that we want to delete a
 // widget and give it the id of the widget to delete
 { 'action' : 'delete', 'widget_id' : $this.attr('id') }, 

 // when the script returns, remove the widget from the page
 function() { $this.remove(); }
 );
 });

Note that when the code refers to

$(this)

it’s referring to the widget to which the event was bound. Now, if we wanted to delete the first widget, we could do:

$('#widget1').trigger('delete');

which is handy but not all that exciting. Let’s go ahead and set up the rest of the custom events …

$('div.widget').

 bind('delete', function(e) {
 var $this = $(this);
 $.post(
 widgetScript,
 { 'action' : 'delete', 'widget_id' : $this.attr('id') },
 function() { $(this).remove(); }
 );
 }).

 bind('edit', function(e) {
 var $this = $(this);
 var $controls = $this.find('ul.controls').clone(true);
 $this.load(
 widgetScript,
 { 'action' : 'edit', widget_id : $this.attr('id') },

 // ajax-enable the form that is returned
 function(html) {
 // populate with new content
 $this.html(html);
 $this.find('form').submit(function(e) {
 e.preventDefault();
 var $form = $(this);
 var url = $form.attr('action');

 // do an AJAX post of the form using
 // the form's action attribute as the URL
 $.post(
 url, 

 // serialize the form data and tack on the action
 // and widget id
 $form.serialize() +
 '&action=save&widget_id=' +
 $this.attr('id'),
 function(html) {
 // populate the widget with the returned
 // html and restore the controls
 $this.html(html).prepend($controls);
 }
 );
 });
 }
 );
 }).

 bind('expand', function(e) {
 var $this = $(this);

 // get the full content from the server
 if (!$this.hasClass('contentLoaded')) {
 $(this).find('div.content').load(
 widgetScript,
 { 'action' : 'expand', 'widget_id' : $(this).attr('id') },
 function() { $this.addClass('contentLoaded'); }
 );
 }

 // mark the widget as expanded, which will
 // show the full content via css
 $this.addClass('expanded');
 }).

 bind('collapse', function(e) {
 // mark the widget as collapsed, which will
 // hide the full content via css
 $(this).removeClass('expanded');
 });

At this point, we have four custom events that we can trigger on any widget (or set of widgets) from anywhere in our code. The ability to run a custom event against a set of elements in a single line is a powerful benefit of using custom events. For example, if we wanted to expand all widgets, we could do:

$('div.widget').trigger('expand');

which would fetch the content for each widget, populate each widget’s content div, and expand each widget to show its content. This ability to trigger custom events on a set of widgets — whether it’s all of them, the first one, the odd ones, a set chosen by the user, or whatever set makes you happy — is one of the most powerful advantages of structuring your features this way.

Hooking it up

The final step in this example is adding controls to the widgets to actually initiate the events. We’ll do this by building a controls element and adding it to each of the widgets. The controls element will look to see which widget it belongs to, and then use the class attribute of individual control elements to trigger the proper event on the widget.

 var $controls = $('
<ul class="controls"/>');

$('
	<li class="edit">Edit</li>
').appendTo($controls);
$('
	<li class="delete">Delete</li>
').appendTo($controls);
$('
	<li class="expand">Expand</li>
').appendTo($controls);

// event delegation on the controls element
$('div.widget ul.controls').click(function(e) {
 // get the actual element that was clicked
 var $t = $(e.target);

 // if the element that was clicked is an
	<li> and
 // is not disabled ...
 if ($t.is('li:not(.disabled)')) {
 // determine which widget the controls belong to
 var $widget = $(this).parents('div.widget');

 // use the class on the li to determine what action to trigger;
 // pass the triggered event a data array containing the
 // element that initiated the event
 $widget.trigger($t.attr('class'), [$t]);
 };
});

$('div.widget').prepend($controls.clone(true));

Note that we’re passing some data when we trigger the event, in the form of an array that contains the element that initiated the event (the <li> that was clicked). With some minor adjustments to the widget event handlers, we can use this data to change the text of the <li> when the widget is expanded or collapsed.

// ...
bind('expand', function(e, $sourceElement) { // ADDED $sourceElement as argument
 var $this = $(this);
 if (!$this.hasClass('contentLoaded')) {
 $(this).find('div.content').load(
 widgetScript,
 { 'widget_id' : $(this).attr('id'), 'action' : 'expand' },
 function() { $this.addClass('contentLoaded'); }
 );
 }
 $this.addClass('expanded');

 // NEW CODE
 if ($sourceElement) {
 $sourceElement.removeClass().addClass('collapse').text('Collapse');
 }
}).

bind('collapse', function(e, $sourceElement) { // ADDED $sourceElement as argument
 $(this).removeClass('expanded');

 // NEW CODE
 if ($sourceElement) {
 $sourceElement.removeClass().addClass('expand').text('Expand');
 }
});

The neat thing here is that this text change is managed by the widget’s custom event handlers; the code for triggering the event (above) stays nice and clean and abstracted, and the “collapse” and “expand” custom event handlers are primed for reuse by other elements that might initiate them (and need their text changed, too).

Conclusion

When everything’s said and done, we have created well-organized code that consolidates the behavior widgets in a few bind() statements, rather than scattering those behaviors across the elements that initiate them. We’ve also gained flexibility, in that it’s easy for any element to initiate a behavior, or for a behavior to be triggered across multiple widgets at once. Finally, we’ve added a simple controls element, which captures a click event and translates it into an event to be triggered on the widget.

See the full code in action (with a dummy back-end).

Custom events are a new way of thinking about jQuery for people accustomed to the traditional model, which puts the emphasis on the element that initiates the event. Custom events, on the other hand, put the emphasis on the object that is being acted upon. Though they can be confusing at first glance, they are a powerful way to organize your code while emphasizing abstraction and reuse.

Rebecca Murphey is a front-end architecture consultant based in Durham, N.C., specializing in jQuery development and standards-based HTML and CSS. You can read her blog or find her on Twitter @rmurphey.

Image Combo Box

Marghoob Suleman’s Javascript Combo Box plugin is a great way to sexy-up your combo boxes within forms. Functionality includes creating combo boxes as images entirely, as well as including images per option. Basically, you can skin the standard combo box.

jQuery DropDown Checklist

This neat jQuery Dropdown Check List widget converts the standard SELECT html element into a nice dropdown with multi tickable options.

McDropDown

Am quite fond of this implementation. As you can see in the screenshot above, McDropDown nicely creates a nested menu of elements to choose from from a simple dropdown. It generates the data from a standard <ul> and <li> implementation and has a huge bunch of options to go with it. Worth checking out.

Droplist Filter

Droplist Filter is really pretty damn good. Every had a dropdown with hundreds of options in it? Sure, you can sort them alphabetically, but that is so time consuming – why not add a nice search filter, hit the Enter key and your option is selected. What a great plugin!

Sexy Combo

Sexy Combo is another take on the customizable combo dropdown box. With Sexy Combo you can skin it to a degree, as well as tell it other options such as the default text you should see before an option is selected, as well as configurables such as making the options appear above the select box rather than below…

QuickSelect

QuickSelect allows you to convert a standard input form element into a nice dropdown of choices as the user types. As you can see form the example above, it has some great flexibility. I typed “aber” into it, and it has found some relatively close matches, rather than exact matches. You can obviously turn this off though, and have it return exactly the string match that you enter.

FlexBox

FlexBox is another alternative to the standard HTML dropdown box. Much the same as the others, skinnable etc.

LinkSelect

LinkSelect is slightly different in its approach whereby it converts a standard A link tag into a selectable list of options. In theory, that could be a text or image link which is a quite nice addition.

Pop!

Whilst not strictly a form dropdown, you get the same effect with the Pop! jquery plugin. As the screenshot suggests, you can put anything in there, so may not be that great for forms, but you never know!

jQuery Color Picker

Again, not strictly a dropdown form option, however the jQuery Color Picker can easily be implemented in the same way to enable the quick selection of HTML colors.

ClickMenu

ClickMenu is another play on the drill down selectable. Using the plugin is as simple as:

$('#list').clickMenu();

Tools to help you learn…

Learning jQuery 1.3	Amazon Kindle 2	jQuery UI 1.6

If you haven’t seen it before, jQuery UI is an awesome layer to the already brilliant jQuery library enabling you to build great, intuitive and interactive Rich Internet Applications. In this Q&A session, Richard D. Worth – Release Manager with the jQuery UI project answers some questions about his early programming days and the future of jQuery UI.

Can you give me a brief history of your programming days? Where did it all start?

I started programming on an Apple ][e. Basic. Next was assembly on a 286. I was really into demos (if anyone remembers those). My older brothers got me started and we would program on whatever PC my dad upgraded to each year or two. Sometimes we'd even have two, so I'd get to play more freely on the older one. 386, 486. I remember the day we got a math co-processor. Oh, and the turbo button! I programmed in pascal, c, pov-ray, qbasic. What else was fun? BBSes, 1200 baud modem, nic.funet.fi, prodigy, compuserve, Mosaic 1.0. HTML. Ahhh. Thanks for the trip.

How did you get involved with jQuery UI? What's the story behind that?

About two years ago I found jQuery and got involved pretty quickly. I started answering questions on the mailing list, created the FAQ, set up http://planet.jquery.com/. After a couple months I heard news that a new version of Interface was being worked on, called jQuery UI, headed by Paul Bakaus. At the time I was working on a drag-and-drop tree (the reason I looked for and eventually found jQuery) and a table editor (where you could drag and select TDs, convert them to THs, merge and split cells, etc.). My first contribution to jQuery UI was some documentation and testing for drag and drop. It came pretty easily, because I was making use of them for both these plugins I needed. I had found an unequaled community in jQuery, and was excited about being a part of a new sub-community growing within it: jQuery UI.

What's next on your things to do list with jQuery UI?

Testing. Lots of test to be written. Static (markup) tests, visual (interactive) tests, unit tests. My eventual goal is full coverage, obviously. Lots to do yet. Also, I'm really anxious for TestSwarm.

Specifications. We've got a marvelous Development and Planning wiki now (http://wiki.jqueryui.com/). We're not just writing code when we have cool ideas. We're planning and designing. I'd like to see us get our specifications to a point where they're sufficient for all tests, code, and documentation to be written from them. Even for existing plugins in so-called "maintenance mode". At this point we're still doing a lot based on current implementation. That can take a lot of time and energy, and too often involves reverse engineering. Plus, it's hard to know what someone might be depending on, or foresee an unintended change. The code alone cannot speak for how a component should behave.

New development, perhaps. It's been a while since I've done any new development on jQuery UI. We've been quite focused as a team for the last 9 months on the 1.7 release. In the end it had only one new plugin, progressbar, and it's the simplest one by a long shot. Now that that's out and we're nearing 1.6 final and 1.7.2, we're taking a look toward 1.8, 1.9, and 2.0. We've got some exciting plugins in the works. I'm particularly interested in working on tree, grid, and menu.

How are you building in performance enhancements into jQuery UI - How do you approach that kind of work?

I did a bit early on. Paul did a lot more. I remember sitting down with selectables at one point. I created a page with like 1,000 items. I wanted to be able to drag the selectable lasso as quickly as possible and have all those items light up and down without a skip. I just kept working on it until the numbers got down. Profiling, refactoring, testing on different platforms. Rinse. Repeat.

Would you say that jQuery, jQuery UI, Mootools and other libraries are forming the basis for what will be the next generation of web applications for the next few years to come? I hesitate to say web 3.0... As the uptake of these gets greater and greater and the feature-set gets even better, the backbone of next generation apps is starting to form I believe. Do you see it that way or do you see a different journey for jQuery and jQuery UI?

I definitely see that. I'm not sure I had that vision when I started contributing to jQuery UI (I just needed a control or two). But it didn't take long. It's clear that Rich Internet Applications are a valuable and growing area of the web, and of software development in general. One of my personal goals, and I think I share it with the rest of the team, is to make Rich Internet Application development as elegantly simple as jQuery has made Ajax and the DOM.

What is it about programming that gives you the bug? Is it the need to solve problems? Or the satisfaction in being able to solve complex problems for example...

I absolutely love problem solving. I always have. I also like the artistic and creative design aspect of programming. For me, too, there's just something about being able to communicate effectively, powerfully even, in the same language with both humans and machines. Code speaks.

Now that IE8 is well and truly out there, what are your thoughts on the new browser? Any significant issues with jQuery UI?

I'm quite pleased with what we have in Internet Explorer 8. It's a great web browser. Will IE6 die tomorrow? Will IE8 be my principal development browser? No. But it's a great browser for all users, and it's finally got some decent development tools built-in. So, I'm happy. As far as issues with jQuery UI, no, I haven't seen anything yet. But we kept a pretty close eye on it through the betas.

What are your tools of choice to get the job done?

Notepad, UltraEdit, Firefox, Firebug, VirtualBox, TortoiseSVN

If you hadn't gotten involved with jQuery UI, what do you think you would be doing instead?

TortoiseGIT

If you could give one tip to new jQuery UI developers, what would it be?

Think and talk about the design. Don't just point at an existing plugin's source code, whether you wrote it or not. Dissect it, analyze it, rip it apart, compare it in detail with everything else out there. Do your homework. And then present what you find in such a way that others can benefit from all that effort.

Richard can be found on Twitter as @rworth, or via his blog at http://rdworth.org

Tools to help you learn...

Learning jQuery 1.3	Amazon Kindle 2	jQuery UI 1.6

Mark It Up

Mark It Up Plugin

Mark It Up is an amazingly powerful new jQuery plugin which deserves some significant recognition. It enables you to quickly modify any standard TEXTAREA within your page into a powerful markup editor, like HMTL, BBCode, Textile, Wiki plus much much more… It’s so simple that instantiating the editor is as easy as:

$('#html').markItUp(myHtmlSettings);

Website: jaysalvat.com
Download: markitup pack 1.1.5

ReType

ReType is a really easy to use way to set your TEXTAREAs up with multi language keyboard support without forcing the user to switch keyboard types. The example given show a nice toggle ability on the TEXTAREA allowing the user to input Russian and German in the same textbox with an English keyboard. It also supports ALT key combinations for a very powerful implementation

Website: myyn.org
Download: jquery-retype

Modal Preview

Modal Preview Plugin

Modal Preview is very simple, it gives you the ability to quickly preview the contents of a TEXTAREA submission before sending it off for processing. Implementation allows a few options like allowing HTML, fade animations, opacity and more:

$('form textarea').modalpreview(options);

Website: devkick.com
Download: ModalPreview

Text Input Limiter

This simple plugin does what a standard TEXTAREA input doesn’t do – it allows you to limit the number of characters you can put into it. Whilst the standard INPUT tags allow this in HTML, TEXTAREAs don’t, so with this plugin you can quickly enable it:

jQuery("textarea").textlimit('span.counter',20)

Download: textlimit.js

HTMLBox

HTMLBox Plugin

HTMLBox is quite similar Mark It Up, although it simply focusses on a standard richtext editor.

Website: remiya.com
Download: HTMLBox 2.8

Resize

Resize allows you to do just that, resize the TEXTAREA. You need to insert a bit of CSS to give you the nice resize image, but other than that it is quite easy to implement:

$('textarea.resizable:not(.processed)').TextAreaResizer();

Website: itsavesyou.com
Download: TextAreaResize

TypeWatch

TypeWatch gives you the ability to know when the user has finished typing or has changed some text in a TEXTAREA. Its actually very similar to the events that already come with jQuery, however what it gives you in addition is the ability to say after X milliseconds DO something.

var options = {

callback:function(){ alert("changed search text"); },
wait:750,          // milliseconds
highlight:true,     // highlight text on focus
enterkey:true,     // allow "Enter" to submit data on INPUTs
}
$("#search").typeWatch( options );

Website: dennydotnet.com
Download: typewatch.js

Tools to help you learn…

Learning jQuery 1.3	Amazon Kindle 2	jQuery UI 1.6