Friday, January 29, 2010

jQuery 1.4

The jQuery Javascript library, without which cross-browser Javascript development is unthinkable, has reached version 1.4.1.

Particularly useful is the ability to create new DOM elements. (See this brief discussion, though no anchor link means you'll have to search for "Quick Element Construction.")

What those docs overlook is the .text property, which enables you to create a proper element:

$("#foo").append( jQuery("<div>", {
id: "foo",
text: "I'm a new DIV element",
click: function() {
$(this).css("backgroundColor", "red");
}}));


or even create a nested elements via .html:
$("#foo").append( jQuery("<select>", {html: "<option value='1'>One</option>"}) );

Sunday, January 24, 2010

The Great Pacific Garbage Patch, local edition

This week's massive storm system seems to have washed up a small taste of the Great Pacific Garbage Patch:


We're doomed.

Thursday, January 21, 2010

Multi-line strings

Javascript doesn't have multi-line strings, but offers a variety of hacks ranging from concatination ("line 1\n"
+"def")
to the CDATA hack, but as always, your milage will vary depending upon your browser.

Python has dedicated multi-line string denominators, namely the triple-quote -- """ and '''. Quite workable, but not as elegant as simply allowing newlines in a string.

C and shell have the backslash:

char * s = "line 1\n\
line 2";

Haskell extends that to the double-backslash:

s = "line 1\n\
\line 2"


PHP, in a rare moment of elegance and usability, treats a newline in a string as a newline.

$s = "line 1
line 2";


Now why is that so hard?

Update: Jake is right: C-style backslashes work in Javascript (at least on Firefox).

Friday, January 8, 2010

stackoverflow.com, in which we circumvent Django's template system

The whole separate-code-from-presentation imperative that inspired Django's template system ... let's say I have my doubts. From my experience, Django's particular approach to templates diverts much too much of my attention to circumventing its limitations.

Update:

In response to Jake's observation that "variables should always be set in the view, not the template," in general, I agree.

But the specific counter-example I'll supply is the very common title example. Let's say you'd like to create a base template like so:

<head><title>{% block title %}</title></head>
<body>
<h1>{% block title %}</h1>
...


And then you inherit from that template:

{% block title %}User Feedback{% endblock %}

This is a very simple, commonplace scenario, and it's simply unsupported. Django will error out on the second call to {% block title %}, and I think that's dumb.

Monday, January 4, 2010

Python's Zipfile library

So you want to generate a big bundle of files all at once, and send 'em in one convenient package? Python's ZipFile library to the rescue! You can create each file, write it to a zip, then send the whole mess over the wire without ever touching the disk! (StringIO is pretty essential as well.)

Ahh, but wait: anyone unzipping your files will find each file marked unreadable/unwritable/unexecutable. And the Python ZipFile docs have zilch to say about it.

This turns out to be the requisite incantation, care of Stackoverflow:

info = zipfile.ZipInfo(name)
info.external_attr = 0777 << 16
zip.writestr(info, bytes)

Obvious, no? Of COURSE you need to bitshift the permissions by 16! (File perms clearly occupy the first 16b of an int, which might even be the standard on Unix, but that doesn't excuse the Python docs' utter silence on the matter.)