A Simple Good Looking Context Menu, for jQuery

Yes, there are loads of context menu plugins already. But they require a fair amount of work to make them look good.

This one is easy to use, small, and looks good.

Demo

Features

  • Tiny library. Only dependency is jQuery.
  • Simple API.
  • Looks good out of the box, with no additional tweaking.
  • Designed to look and behave like a standard Windows context menu.
  • There’s so little code, it should be easy to add your own custom features.

The menu looks like this:

Installation

Include the files jquery.contextmenu.css and jquery.contextmenu.js in your page <head>. You also need jQuery. It is recommended that you use the HTML 5 DOCTYPE to ensure rendering consistency.

<!DOCTYPE html>
<html>
  <head>
    <script src="jquery-1.6.2.min.js"></script>
    <script src="jquery.contextmenu.js"></script>
    <link rel="stylesheet" href="jquery.contextmenu.css">
    ... rest of your stuff ...

You can get the files from here:

Usage

The plugin introduces a contextPopup() method to the jQuery object.

Assuming you have an element that you’d like to bind a context menu to:

<div id="mythingy">hello</div> 

You can wire up a context menu like this:

$('#mythingy').contextPopup({
  title: 'My Popup Menu', 
  items: [ 
    { label:'Some Item',
      icon:'icons/shopping-basket.png',
      action:function() { alert('clicked 1') } }, 
    { label:'Another Thing', 
      icon:'icons/receipt-text.png', 
      action:function() { alert('clicked 2') } },
    // null can be used to add a separator to the menu items
    null,
    { label:'Blah Blah', 
      icon:'icons/book-open-list.png', 
      action:function() { alert('clicked 3') } }
  ]});

Icons

The icons should be 16×16 pixels. I recommend the Fugue icon set (shadowless).

Go get it

It’s over on GitHub:

A slide-show in 2 lines of JavaScript

A while back, I needed to create a quick slide-show. I decided to hack it up in HTML – mostly to make it easier to track the diffs in version control and make it easy to distribute. There are many frameworks out there to build sexy HTML based slideshows, but I only had 10 mins to prepare and didn’t want to take the chance of hitting a road block – so I did it myself from scratch. Here’s how…

Step 1: Content (HTML)

Firstly, let’s get some content on the page. In my case, I just had a list of sentences – one per slide. But you could of course do whatever you like here – embed images, bullet lists, etc.

<!DOCTYPE HTML>
<html>
  <head>
    <title>My slides</title>
  </head>
  <body>
    <section>This is the <em>first</em> slide</section>
    <section>This is the <em>second</em> slide</section>
    <section>This is the <em>third</em> slide</section>
    <section>This is the <em>penultimate</em> slide</section>
    <section>And this is the <em>final</em> slide</section>
  </body>
</html>

I used the HTML 5 section element, as that is the most semantically relevant tag. And because I’m using HTML 5 tags, I added the HTML 5 DOCTYPE.

Here’s how it looks: Example 1

Step 2: Transitions (JavaScript)

Firstly, a bit of CSS to make each <section> cover the entire page, and hidden when the page loads (imagine a deck of cards, but you can’t see the first one yet).

<style>
  section { display: none; position: fixed; top: 0; left: 0; width: 100%; height: 100%; }
</style>

Next, a bit of JavaScript at the bottom of the page to find the first section and fade it in when the page loads. I used jQuery because it makes it really easy to express this stuff.

<script>
  var currentSection = $('section').first().fadeIn();
</script>

This is assigned to a the variable “currentSection” as we want to keep track of which slide we’re on for the transitions.

Now the transition. What I want to say is… “whenever the body is clicked or a key is pressed, fade out the current section, find the next section (which will now be referred to as currentSection), and fade that in”.

With jQuery, that’s:

$('body').bind('click keypress', function() { currentSection = currentSection.fadeOut().next('section').fadeIn(); });

So now we have transitions (click or keypress).

Here’s how it looks: Example 2

Step 3: Prettify (CSS)

Now make it look how you want. Here’s the CSS I used:

<style>
  body    { color: #ffffff; background-color: #000000; font-family: arial; font-size: 40px; -webkit-user-select: none; }
  section { display: none; position: fixed; top: 0; left: 0; width: 100%; height: 100%; text-align: center; padding-top: 200px; }
  em      { color: #ffff00; font-family: serif; font-size: 150%; }
</style>

That’s all.

See the final result: Example 3

An advantage of building it yourself is you’re in complete control, and can make it do, well, anything.

Oh, and here’s the original slideshow I hacked this up for: 10 reasons why I’m not a cool Java developer (a 5 minute lightning talk at the Google Open Source Jam)

Node.JS would really benefit from LibFFI

Having recently built a simple LDAP library that required a bit of C++, I think Node would really benefit from LibFFI bindings.

LibFFI allows C functions to be called dynamically at runtime from another language. There are LibFFI bindings for Python (ctypes), Ruby (Ruby-FFI) and Java (JNA), amongst others.

If FFI bindings existing for Node, you’d be able to call native C functions without ever leaving the comfort of JavaScript. Apart from making the code a lot simpler, it also avoids the need for a build step (nothing to compile), and hide the complexities of working with threads in C++.

Here’s how it would work…

Step 1: Write some JavaScript that bindings to a native library and exports C functions as JavaScript.

var ffi = require('ffi'); //
var ldap = ffi.createLibrary('ldap', { // load libldap.so
  // exporting these functions
  // (C function name, [C arg types], C return type)
  open: ffi.exportAsync('ldap_open',
    [ffi.string, ffi.string], ffi.pointer),
  simpleBind: ffi.exportAsync('ldap_simple_bind_s',
    [ffi.pointer, ffi.string, ffi.password], ffi.int),
  unbind: ffi.exportAsync('ldap_unbind',
    [ffi.pointer], ffi.integer)
});

Yes, this looks messy, but it’s a lot less painful than doing it in C++.

Step 2: Call your native libraries through the JavaScript bindings.

ldap.open('somehost', 389,
  function(err, ldap) {
    if (!err) {
      ldap.simpleBind(ldap, someUserName, somePassword, 
        function(err, result) {
          if (!err) {
            print('Authentication result = ' + result);
            ldap.unbind(ldap);
          }
        }
      });
    }
  });

The native functions would still execute asynchronously in a background thread, so as not to tie up the main Node event loop. The usage pattern is the same as the rest of Node.

Writing the code still involves a basic knowledge of C, in that you need to read the documentation for native libraries and understand what it means. But you’d write all your code in JavaScript and avoid the hassle of the build system and platform specific linking.

There’s a lot of native libraries out there – this would open up a lot of doors.

Who’s going to take a crack at it?

LDAP authentication with Node.JS

I’m a big fan of Node.JS.

It has a large collection of third party add-ons, but it lacked anything for LDAP authentication – something I need for web-apps.

So, I created a small library with a single function that authenticates a username/password against an LDAP server.

var ldapauth = require('ldapauth'); 

ldapauth.authenticate('some.host', 389, 'someuser', 'somepassword',
  function(err, result) {
    if (err) {
      print('Error');
    } else {
      print('Credentials valid = ' + result); // true or false
    }
  });

(Full example)

Under the hood it’s a native C++ module using OpenLDAP.

To use it, grab the ldapauth.node binary and include in your Node path (or reference directly when calling require()). The binary is built for 64bit Linux – if you use another platform, you’ll have to get the code and build it yourself.

Introducing Smoothie Charts

There’s tons of great JavaScript charting libraries out there. Too many to choose from. I’ve just made it worse by adding yet another to the mix.

Before I go on, I want to balance karma a little – if you’re looking for a JavaScript charting library, just use Flot. I don’t know anything about your requirements, but I like my chances – everyone loves Flot (including me). It’s small, simple, great looking and flexible.

So why another library? Well, I had a very specific problem… I want to show real time streaming data pushed over a WebSocket. Although many of the charting libraries allow you to dynamically update data, none have really been optimized for a constant stream of data. I tried many (seriously, at least 40 libraries) and the constant updates just looked too jerky.

So Smoothie Charts was born. It’s not big, and it’s not clever. And it only works on Chrome and Safari. And it doesn’t support legends. Or pie-charts. In fact, it’s inferior in virtually every way to a library like Flot. But, it’s very good at displaying streaming data.

I use it for building web dashboards monitoring active system load (that look something like this).

Use it, hack on it, and contribute back.

New QDox lead – Robert Scholte

I’d like to announce the new lead for QDox, Robert Scholte.

Anyone who’s been following the project for the past year would have seen that Robert has made a tremendous number of contributions to all areas of QDox, including bug fixes, build, docs/website, releasing, user support and admin. If you follow the project further back, you’ll see that Robert has actually done more on the project in the past year than was done for the combined 6 years before that…. impressive.

I originally wrote QDox back in 2002, as a stop gap until annotations were added to the Java language. It was quickly picked up tools such as XDoclet. I always thought (and hoped) that once annotations made it into the language, it would be redundant. Yet it lived on. Unlike the JDK Annotation Processing Tool (APT), it could process source code rather than byte code in a simpler and faster manner. And it provided access to information that the JDK didn’t make available (e.g. parameter names). And it was useful where annotations still did not exist, like in JavaME. So, even in 2010, it still lives on and is used in tools such as Maven and Eclipse. But I cannot invest the time into it that I once could.

Given Robert’s commitment to the project, I can think of no better person to lead the project. He’s done an astounding job. Robert has kindly accepted this role and I’m delighted to hand it over to him.

I’d also like to use this opportunity to thank Paul Hammant, Mauro Talevi and Dennis Lundberg for their ongoing efforts on the project.

JUnit/TestNG tip: Diffing Lists

A little cheap and cheerful JUnit/TestNG tip…

Problem: You’ve got two lists that you want to compare using assertEquals(). But when the assertion fails, the error message kinda sucks.

java.lang.AssertionError: expected:<[Person{name=Joe,starsign=Virgo,sex=Male}, Person{name=Jaimie,starsign=Libra,sex=Female}, Per
son{name=Ewan,starsign=Capricorn,sex=Male}]> but was:<[Person{name=Joe,starsign=Virgo,sex=Male}, Person{name=Jaimie,starsign=Scor
pio,sex=Female}]>
   at org.junit.Assert.fail(Assert.java:74)
   at org.junit.Assert.failNotEquals(Assert.java:448)
   at org.junit.Assert.assertEquals(Assert.java:102)
   ...

It’s really tricky to see exactly where the differences are in the list.

Solution: Join both the lists into a string, delimited by newlines and assert that instead. That will force your IDE’s multiline differ to kick in.

junit-diff(click image to see the rest of it)

This relies on having a sensible toString() method on your list items.

If your IDE doesn’t do this, or you can’t run your tests from your IDE, you should really get that seen to.

Here’s a method to do it:

public static <T> void assertList(List<T> actual, T... expected) {
  assertEquals(join(expected, "\n"), join(actual, "\n"));
}

That’s all. Now get back to work.

SiteMesh 3 preview

I’m pleased to announce a preview of the next generation of SiteMesh.

Before I go on, here’s a big disclaimer: This is not a stable release version yet… it’s not even a beta… it’s an alpha… a first alpha.

But anyway, I decided to launch it in this state, as I think it’s a huge improvement over SiteMesh 2, and I’d like to get your feedback earlier so it can be fed into the final product.

Quick links, for the impatient:

So what’s new? Well, everything. The 10 year old code base has been thrown away and rebuilt from the ground up. At the core of it is a new content processing architecture that performs roughly three times as fast as SiteMesh 2 with half the memory usage.

Along with that:

  • Decorator chaining. Compose pages from multiple layouts and decorators.
  • Decoupled from templating systems. Decorators can be produced with any technologies – you are free from JSP.
  • Offline site generation. Apply decorators as part of a build step. Accessible through Java API, Ant task and command line tool.
  • Simplified configuration. Use XML, Java or plug in your own system.
  • Clean API provides extension points for adding custom processing rules (e.g. on the fly page transformations).
  • Licensed under Apache Software License v2.0.

So what’s the same? The values of SiteMesh have not changed – simplicity, robustness and performance.

You can learn more about SiteMesh 3 on its new website: www.sitemesh.org

What about compatibility with SiteMesh 2?

This was a hard decision to make, but SiteMesh 3 is not backwards compatible with SiteMesh 2. Upgrading will require work beyond just upgrading a library. Over the coming weeks, I shall produce some guides and tools to make this transition easier. Though this may be frustrating to many users, it was becoming too hard to make changes to SiteMesh 2 based on limitations to its design. SiteMesh 3 addresses these and will make way for a lot of great features and improvements in years to come.

Meanwhile, SiteMesh 2 will continue to be supported until 2011 – though this will mostly be critical bug fixes only. The majority of development effort will be focussed on SiteMesh 3.

So give it a go, and give us feedback. But please remember that it’s only an alpha!

SiteMesh logo design contest

I’m looking for a gorgeous new logo for SiteMesh, so I”ve just launched  a logo design contest on 99designs.com. It will run for 7 days and has a prize of $400 – of course, the real prize is the good feeling of contributing back to the SiteMesh project ;).

http://99designs.com/contests/23286

The brief…

Theme:
Clean, simple, modern.

Font:
Feel free to use whatever font you like, or create your own. Remember that SiteMesh is associated with clean and simple. If you use (or derive from) an existing font, please specify what font this is and where it can be obtained.

Background:
The logo should be on a flat (single color) background, so it is easy to place in different places. If the background is not white, please also supply a variation of the logo that has a white background (e.g. to use in print outs).

Color scheme:
Up to you.

Variations:
Would like two variations of the logo:
1. The worded logo: This focus of this must be the word ‘SiteMesh’. It will typically be used in the header of every page of the website, documentation, etc.
2. The icon based logo: This would typically appear in small square placements (e.g. a desktop icon). It does not need to contain the text ‘SiteMesh’ but should be easy to recognize as associated with the worded logo. Should look good at small sizes (e.g. 42×42).

Format:
Please supply original high-resolution files of whatever tool you use to create the logo (e.g PSD), so I can make modifications and rescale in the future as necessary.

http://99designs.com/contests/23286

Running SiteMesh on AppEngine

Does SiteMesh work on Google AppEngine (Java preview)?

Short answer: Yes.

Longer answer: Yes. It does. So long as you check 2 things…

1. Upgrade

You need SiteMesh version 2.4.2 or greater. Earlier versions do not support AppEngine.

Download here

2. Disable static file serving

If you want decorators to be applied to static content (e.g. to .html files), the following needs to be added to WEB-INF/appengine-web.xml:

<static-files> 
  <exclude path="**"/> 
</static-files>

This forces the static resources to be served by the Servlet engine, rather than a separate static web-server. Without this, the files served by the static web server will not be decorated.

Happy AppEngining.