The drawImage method of the canvas context is used to write image data onto the canvas from an HTMLImageElement, from another canvas or from an HTML <video> element. I was attempting to draw the contents of an <img> tag into the canvas but almost every page load was getting the following error from Firefox:

uncaught exception: [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIDOMCanvasRenderingContext2D.drawImage]“  nsresult: “0×80040111 (NS_ERROR_NOT_AVAILABLE)”  location: “JS frame :: http://localhost/canvas/js/interface.js :: anonymous :: line 114″  data: no]

After much confusion I realised that I was setting up the canvas in a DOM ready event handler so it made sense that if the image hadn’t also loaded, its data wouldn’t be available to be drawn. Switching to the onload event cured the issues.

I started with the following:

<mx:SWFloader source="http://www.example.com/external.swf" complete="loadComplete(event)" />

The first security sandbox error was about external.swf not being able to access the stage property. A quick view of the SWFLoader documentation lead to adding the trustContent property:

<mx:SWFloader source="http://www.example.com/external.swf" complete="loadComplete(event)" trustContent="true" />

After switching debugging to a local server on http://flex so that it wasn’t running in the local security sandbox, the stage error went away.

However, I ended up with a very strange URL not found error along the lines of ‘Error #2035: URL Not Found. URL: http://flex/[[IMPORT]]/www.example.com/external2.swf’. Looked like the third-party SWF was in turn trying to load a further SWF. After discussions with the developers, it turned out they were loading another SWF from the same location by using the LoaderInfo.url property.

Digging around in the SWFLoader source, reading lots of documentation about Flash’s security model and lots of unsuccessful searching lead me to what appears to be an undocumented feature. When the external content was imported into my application’s SecurityDomain the loader URL is changed to the one shown above with [[import]] in it. This means that their URL building was failing to produce the correct URL.

The solution was to remove the trustContent property so that the content wasn’t loaded into the security domain. Initially the stage error came back but by adding Security.allowDomain(‘www.example.com’) allowed the loaded SWF access to the stage. The same could have been achieved with a crossdomain.xml, I would have thought.

Creating the System Tray Icon

Within the WindowedApplication we can embed a graphic to be used as the icon. I’m using a 16 x 16 PNG with full alpha transparency.

[Embed(source="icons/tray.png")]

private var TrayIcon:Class;

By attaching a handler to the initialize event, an instance of the embedded image is created (cast to a Bitmap) and the bitmap data extracted. This data can then be assigned to the array of icons for the application. I’m also setting the tooltip text. This code is wrapped inside a check that the system support system tray icons.

if (NativeApplication.supportsSystemTrayIcon) {
    var trayIcon:BitmapData = Bitmap(new TrayIcon()).bitmapData;
    SystemTrayIcon(nativeApplication.icon).bitmaps = [trayIcon];
    SystemTrayIcon(nativeApplication.icon).tooltip = 'This text will appear when hovering over the icon';
}

The icon also supports event handlers for various ScreenMouseEvent types, meaning you can handle clicks, right clicks and so on, depending on your requirements.

Creating a Context Menu

The context menu for the tray icon is created as a standard NativeMenu (with a number of NativeMenuItem items) and then assigned as the menu for the icon. The sample below defined a menu with an exit option which is handled by a separate handler function.

var menu:NativeMenu = new NativeMenu();

var exitMenuItem:NativeMenuItem = new NativeMenuItem("Exit");
exitMenuItem.addEventListener(Event.SELECT, exitApplication);
menu.addItem(exitMenuItem);

SystemTrayIcon(nativeApplication.icon).menu = menu;

The menu will now appear on a right click on the tray icon, there is no need to explicitly wire this interaction together.

SliceHost define themselves as a ‘hosting company for people who know there stuff’ and after 2 years of building and maintaining a Linux server as part of my job I figured I either knew my stuff or could at least pretend I did. At the time, their popularity was such that you had to wait until they could meet your requirements, the wait dependent on the slice size and pre-payment term you wanted. It looks like customers now get to build their slice immediately.

On the plus side, I used the weeks to decide which Linux distro to use on my slice. After considering Fedora 8 in the vain hope it would be similar to RedHat, I eventually opted for Ubuntu 7.10 (aka Gutsy Gibbon) after noting that there were more articles on the SliceWiki than for other distros.

Security

Once I built the slice there were a few basic security tasks to get out of the way before going any further. The getting started article was a good place to start and covers all the security that in the past my hosting company would have done all this for me. So I changed the root password, created a new user and gave them sudo privilege, turned off root ssh access and as an extra security I also changed the ssh port to something memorable rather than 22. The article also covers using iptables as a firewall so I followed it to the letter, not having much previous experience with iptables.

The second part of the guide goes into more detail than I felt I needed so I limited myself to updating sources and upgrading the system as well as installing the build essentials. At the time I thought I would be building Apache, PHP and MySQL from source as I have had to do on Red Hat before now. How wrong I was…

In the MooTools 1.1 version I had a base class, ‘Widget’ which I would extend as below:

var DialogBox = Widget.extend({ … });

Widget implements both Options and Events which allowed me to create a set of events the widget can fire, handlers for which can be added through options, as such:

var DialogBox = Widget.extend({
  options : {
    onCancel : this.close.bind(this)
  }
  ...
});

Because extend is a method of Widget, its ‘this’ is the object itself and, provided there is a close method, the event handler for ‘cancel’ is set up.

MooTools 1.2 introduces a new syntax for extending objects:

var DialogBox = new Class({
  Extends : Widget,

  options : {
    onCancel : this.close.bind(this)
  },
  ...
});

Now, the ‘this’ is actually the window object so the cancel event is actually handled by the window.close method – not quite the functionality intended!

After digging around in the MooTools code, in particular the Request.HTML class, I found what appears to be the only way to default events in options. By setting the option before calling setOptions (if it isn’t already set), the event handler is correctly assigned:

var DialogBox = new Class({
  Extends : Widget,

  options : {
    ...
  },

  initialize: function(options) {
    options.onCancel = options.onCancel || this.close.bind(this);
    this.setOptions(options);
  },
  ...
});

The binding is now done on instantiation so the correct close method is assigned as the cancel event handler.

Traditionally, JavaScript form validation involves calling a validate function when the onSubmit event of the form is fired, with the function returning whether or not the form validated. In most cases, if validation failed the user is informed; in the best cases with a highlighted field and inline message, in the worst with an alert box.

With recent trends in website / web application development moving towards more responsive pages and the use of Ajax to speed up user interaction, this system has been crying out for a radical update. Until now.

Live Validation allows a developer to hook any number of validation requirements directly onto form elements. As a user interacts with the field they are given real-time feedback as to whether their data is valid.

The open-source library is available for download to work either with the Prototype framework or as a stand-alone version. The Prototype version integrates well with Ruby on Rails applications and the coding conventions of Live Validation will be very familiar to Rails developers but simple enough to be understood by anyone with basic JavaScript knowledge.

Once the library is downloaded and included on your page, adding validation couldn’t be much easier. The LiveValidation object is instantiated with an id of (or reference to) the input element and then rules added to the object. The following example validates for a required field with an id of ‘f1′:

var f1 = new LiveValidation(‘f1′);
f1.add(Validate.Presence);

LiveValidation also allows chaining of rules and even the object so that it is possible to simply have a single line of code provide very powerful validation rules. The example below requires the field to be filled and to be numeric:

new LiveValidation(‘f1′).add(Validate.Presence).add(Validate.Numericality);

The range of validation rules doesn’t end with required fields and numbers, Live Validation also covers regular expression pattern matching, numeric ranges, length ranges and inclusion / exclusion, amongst others.

Overall, Live Validation’s powerful features, simplicity of use and extensive on-line documentation, combined with it’s graceful degradation and real-time user interaction add up to provide a fantastic replacement for an ageing concept.

Update: Since writing the article there have been two point-releases of LiveValidation and it is now on version 1.2. Added is support for select boxes, time delayed checking and automatic onSubmit validation. Full details are available on the blog.