textpopup and hebrewKeyboardThe Hebrew pop-up keyboard on the YI site search box was always hard-coded and kind of obtrusive, so I wanted to make a jQuery plugin to add a keyboard to any input type="text" or textarea. To make it more flexible, I factored it into a general-purpose popup widget and the keyboard itself.
| Rosh Hashana 1 | Rosh Hashana 2 | Yom Kippur | |
| Maariv | Person 1 | Person 2 | Person 3 |
| Shacharit | Person 4 | Person 5 | Person 6 |
| Musaf | Person 7 | Person 8 | Person 9 |
| When | What | Who |
| Rosh Hashana 1 | Maariv | Person 1 |
| Rosh Hashana 1 | Shacharit | Person 4 |
| Rosh Hashana 1 | Musaf | Person 7 |
| Rosh Hashana 2 | Maariv | Person 2 |
| Rosh Hashana 2 | Shacharit | Person 5 |
| Rosh Hashana 2 | Musaf | Person 8 |
| Yom Kippur | Maariv | Person 3 |
| Yom Kippur | Shacharit | Person 6 |
| Yom Kippur | Musaf | Person 9 |
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.
Continue reading ›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):
Continue reading ›$.fn.sendkeys PluginThe 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="←"/><input type="button" name="{rightarrow}" value="→"/><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>
$.fn.sendkeys PluginI 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!
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.
Continue reading ›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.