12 May

jQuery Tab Trap plugin

I was reading an article on accessible dialogs in web pages, and the author discussed the desirability for screen readers to have the focus trapped in confirm type dialogs until the dialog disappears. The article shows a method for keeping the keyboard focus. It won’t prevent clicking elsewhere, but screen readers navigate by the keyboard rather than the mouse.

That’s fine, but it relies on event capturing rather than bubbling and applies to mouse clicks as well as keyboard navigation.

Here’s a jQuery plugin that will handle tab and shift+tab events, is keyboard specific and uses event bubbling. It is dependent on jQuery and jQuery UI (for “:focusable”). You could implement “:focusable” yourself to get get rid of the jQuery UI dependency.


22 Dec

How to create an OpenSocial/Social Web Gadget Feature

Features are a way for OpenSocial/Social Web gadgets to request JavaScript library support from the OpenSocial/Social Web container. Creating a new feature will give 3rd party gadgets and the OpenSocial container easy access to your custom JavaScript code – your “feature”.

Features can be divided into code that runs in the container and code that runs in the gadget. For Apache Shindig (the reference implementation of the OpenSocial container spec), the code that runs in the gadget will be automatically injected by a Shindig servlet when it serves the gadget to the browser. Gadgets tell the container which features they need or support in their ModulePrefs. The Shindig container page will need to request the container specific feature code by including the feature name in its call to the Shindig JS servlet.

Including a Feature in a gadget

Including a Feature in the Container (Shindig)

Defining features

XML files describing features are used by the OpenSocial server to know where to look for features’ gadget and container code. These XML files also let the server know what dependencies the features have.

Create a single JavaScript file if a feature needs the same code to run in the container and the gadget. If different code is to run in the gadget and container, then separate the feature code into different JavaScript files. For example, my-feature-gadget.js and my-feature-container.js. The JavAscript files can be named anything. The XML will tell the server what the file names are. The XML file containing the feature XML is generally placed into a feature specific folder along with the feature’s JavaScript files.

Feature XML

The same file can be referenced in both the gadget and container elements if the gadget code is not specific to the gadget or container.

Script tags in the XML could have JavaScript in them rather than referencing a source file.

Shindig and feature XML

Shindig has a features.txt file in its classpath that contains a line for each feature.


This file is a list of XML files that Shindig will reference when it needs to locate a feature’s source files. By convention, most features name their XML file feature.xml, but that is not necessary. It can be anything as long as the features.txt file references it. Add a line to features.txt for the new feature, and ensure the folder containing the XML and JavaScript files are where they should be within the features folder.

Feature Code

There is no defined way that a feature must be coded. The code placed in the JavaScript files is just like any other JavaScript. It is executed as is. Unless there is a good reason not to, a good convention to follow is to make feature code available on the “gadgets” global object. The sample code below could be used in either the gadget or container JavaScript.

Feature code

The feature code will then be executed using gadgets.myfeature.getX().

Feature Parameters

Sometimes a gadget will need to provide parameters to a feature. This is done in the ModulePrefs.

Passing a parameter to a feature

Get the parameter in the gadget

Shindig has a method called “gadgets.util.getFeatureParameters(featureName)” which seems like the method to use to get the value of “x”. It won’t work, however, because gadget.util.init never gets called with the gadget metadata. Shindig does call gadgets.config.init with the gadget metadata though, so the config feature can be used to extract the custom feature parameters.

Finding feature parameters from within a gadget

The location of the feature parameters within allFeatureConfig could vary depending on the dependencies of the feature. Inspect allFeatureConfig in a debugger to figure out where the parameters is.

Get the parameter in the container

Shindig has a metadata servlet that returns gadget metadata so that the container can load the gadgets as it sees fit. The gadget metadata returned is a JSON object that has the feature parameters in it. It can be accessed as metadata.gadgets[<index of gadget>].featureDetails[“x”].

Shindig Caching

Shindig does not have a way to turn off feature caching, so any additions or changes to files within the feature folder will require a Shindig restart.


Thanks to Dr. Chuck for his blog about Shindig features that got me going in the right direction.

25 Jan

Bare bones JQuery UI widget

Here is a minimal JQuery UI widget that can be used as a starting point for writing new widgets.

25 Jan

Running specific JUnit tests within a test class using Ant

The test class, FooTests.java.


Verify the tests run. Replace the colons with semi-colons in windows.

The Ant build file, build.xml.

Run all tests.

Run only the second test by specifying the “test-methods” Ant property on the command line.

Run only the second and third tests.