Hacking at 0300

Metadata

I put the idea that the metadata plugin should be extensible out on the jquery discussion group, but it got no attention, so I'm documenting it here.

OK, this is the final update to the widget subclassing. Rather than creating a new method, $.widget.subclass, I created a single base widget $.ui.widget that does nothing but includes the Aspect-Oriented-Programming code and a subclassing method. I put everything in the $.ui namespace (since namespacing plugins doesn't work anyway, all plugin names need to be globally unique). I removed the callSuper method, since this.callSuper('ui.widget', 'method', args) is no better than just doing it straight, $.ui.widget.prototype.method.apply(this, args).

Without further ado, here's the code (download):

The phone pad below is messed up in Internet Explorer. I know. I don't care anymore. The plugin, however, works.

	$('div.test input:button').click(function(){
		$('.output').sendkeys($('div.test input:text').val());
	});
	$('.phonepad input').click(function(){
		$('.output').sendkeys(this.name || this.value);
	});

<div>
<textarea class="output"></textarea>
<br/>
<input type="text" class="output" />
<div class="phonepad"><input type="button" name="{leftarrow}" value="&larr;"/><input type="button" name="{rightarrow}" value="&rarr;"/><input type="button" name="{backspace}" value="BS"/><input type="button" value="7" /><input type="button" value="8" /><input type="button" value="9" /><input type="button" value="4" /><input type="button" value="5" /><input type="button" value="6" /><input type="button" value="1" /><input type="button" value="2" /><input type="button" value="3" /><input type="button" value="*" /><input type="button" value="0" /><input type="button" value="#" /></div>
<div class="test"><input type="text" /><input type="button" value="test"/></div>
</div>

The $.fn.sendkeys Plugin

I wanted to make a general-purpose onscreen keypad, and wasted a huge amount of time trying to find a way to simulate a keypress. $(element).trigger("keypress",...) won't work. Neither will keyup or keydown. For security reasons, I guess, you can't tell an element to pretend a key was pressed. The browser is too worried that you will access menus or something.

So I wrote my own plugin and named it after Microsoft's sendkeys which does similar things. For any element elem that is a <textarea> or <input type="text">, $(elem).sendkeys(string) inserts string at the insertion point or selection. It's the insertion point sensitivity that makes it more sophisticated than elem.value += string.

I added some potentially dangerous code to automatically turn code examples (things in <code> elements with class demo into actual HTML or javascript that are added to the post. The javascript part works; I used it in the last post; here's testing the HTML insertion:

  <div style="background: purple; margin: 2px">This is a test</div>

And more testing:

  <div style="background: #080; margin: 2px">This is a test</div>

This is an updated version of a tutorial I wrote a bit back, improved thanks to conversations with Scott Gonzalez of the jQuery UI team. Thanks!

Avoiding Bloat in Widgets

A while back, Justin Palmer wrote an excellent article on "Avoiding Bloat in Widgets." The basic premise (no suprise to anyone whose ever dealt with object-oriented programming) is that your widgets should not do everything possible; they should do one thing well but be flexible enough to allow others to modify them.

He describes two ways of extending objects: subclassing and aspect-oriented programming (AOP). Subclassing creates new classes, while AOP modfies the methods of a single object. Both can be useful.

I like the idea of syntax coloring, so let's see if Chili works:

alert('Hello, world');

and another: <div>Hello, <em>world</em></div>

I'm trying to be as HTML5-compliant as possible, at least in the sense of using their standards rather than making up my own, so the Chili setup I'm using is:

    $.extend(ChiliBook, {
        automatic: false,
        codeLanguage: function(el){
            // use the HTML5 language class
            var recipeName = /language-(\S+)/.exec(el.className);
            return recipeName ? recipeName[1] : '';
        }
    });
    $(function(){
        $('code[class*=language-]').not($('pre code')).chili({lineNumbers: false})
                                  .otherwise().chili({lineNumbers: true});
    });

 

Sweet! The idea of the above code is to look for a class that starts with "language-" and use that as the recipe for Chili (rather than Chili's built-in way of taking the entire className). It also assumes that any code in a pre element should have line numbers, and anything else should not. It uses the cute and brilliant otherwise plugin from http://groups.google.com/group/jquery-en/browse_thread/thread/6be2a127822a108d.

Update: It looks like line numbering works only intermittently. Oh well; I won't fix it.

jQuery encourages using namespaces for methods in the $ namespace, like $.foo.bar() rather than $.bar(). This works for $ because methods don't expect this to refer to anything specific, and the way javascript works is to assign this to the last-named object, so in $.foo.bar(), this refers to $.foo.

This idea fails for plugins, however, since plugins expect this to refer to the jQuery object that started the chain. If I define $.fn.bar = function(){}, then when $(...).bar() is called, this refers to $(...), just as we want. But if I define $.fn.foo.bar = function(){}, then when $(...).foo.bar() is called, this refers to $(...).foo, which is an object that knows nothing about jQuery. There's no way to make an object reference return something else.

But all is not lost. We can define a function that returns an object, and that function can use this to set the returned object to be just like a jQuery object, but with the desired namespaced methods in it. The inefficient way to do that is to copy the new methods into the jQuery object, but if we can manipulate the prototype chain directly (as we can in Firefox) we can add our new methods to the chain without copying.

Update: this post is obsolete. Please see the updated version

Avoiding Bloat in Widgets

A while back, Justin Palmer wrote an excellent article on "Avoiding Bloat in Widgets." The basic premise (no suprise to anyone who's ever dealt with object-oriented programming) is that your widgets should not do everything possible; they should do one thing well but be flexible enough to allow others to modify them.

He describes two ways of extending objects: subclassing and aspect-oriented programming (AOP). Subclassing creates new classes, while AOP modfies the methods of a single object. Both can be useful.

This was written largely to help me make sense of using UI to create my own widgets, but I hope it may help others. "Widget" to me means a user-interface element, like a button or something more complicated like a popup date picker, but in jQuery UI terms it means a class, members of which are associated with HTML elements; things like Draggable and Sortable. In fact, not everything that I would have called a widget uses $.widget; the UI datepicker does not.

Unfortunately, only the administrator seems to be able to use unfiltered HTML.

I also needed to use the Text Control plugin and set formatting to "No Formatting" to prevent escaping the single quotes. But it seems to work.