In case anyone’s curious, this is the UML chart with WAE I churned out for my To-Do manager. The model is pretty simple: Users have Lists, Lists (called “Documents”) have Tasks, Tasks have DoneDates. Task properties include a minimal number of days that a task can be allowed to slide, and a maximal amount. An algorithm, initially in python but I intend to migrate it to javascript and do the math on the client to reduce server load, figures out how to decorate the task list based upon the task profile and a collection of done dates “around today.”

This chart is very shorthand-y: in many cases it’s a matter of my knowing what I meant. The boxes with circles in the upper right hand corner are controllers; the ones with squares are views. There’s some confusion on the chart as to whether or not there are controllers that are view generators; the one labeled “doc builder” appears to be, but there’s no corresponding view generating controller, I don’t think, for Lists of Lists. There are also weaknesses in WAE that I’ve never gotten around to addressing, which is that it was first cooked up in 2003 and has almost no sense of ajax or component-driven view management, and has a whole bunch of notation for frames that can’t really be ported over to ajax.

In 0.96, the way you defined a database table as being “administratable” was to add to the Python definition of the table a subclass entry class Admin: pass.  The Administration app would automagically pick out those tables that were administratable and they would appear in the admin interface.

In 1.0, it’s completely different.  Instead, you must create in your application, next to your models, a file admin.py which contains registry lines for each model and, optionally, an administration interface class that describes how the model should be administered.  It’s all covered in the Django tutorial which doesn’t really help you if all you have is the book.

This makes obvious sense. Administrative details are independent of model details, and although the argument could be made (and was made) that they’re implementation details of the model, making it a separate decorating class also makes just as much sense. Yes, it means that the details of a class (the administrative class of a model) are in two different places, but it also means that administrative features of your application can be restricted in deployment just by deleting the admin.py file.

You did keep a copy of admin.py in your source control, right?

It’s useful to write that knowledge down.

Last night, I ginned up a quick wiki, dropped in a theme I liked, and put the whole thing up. It only has a few entries right now but they should be enough to show what I’m trying to accomplish. If you find this a useful idea, please contribute to it and publicize it:

The Javascript Framework Phrasebook

import inspect
def _line():
    info = inspect.getframeinfo(inspect.currentframe().f_back)[0:3]
    return '[%s:%d]' % (info[2], info[1])

Use as needed.

The real trick was to stop sending huge masses of javascript back and forth with every operation, but instead to encapsulate all of the javascript FireWatir generates and transmits per transaction into a javascript library, upload that once, and then just issue one-line calls to the JSVM through the library. This skips a very expensive interpretation step and allows context identity to be maintained more explicitly.

Also, on the client (python) side, finding objects became a matter of doing things like:

doc.input(name="username").set("user")
doc.input(name="password").set("mypassword")
doc.input(typ="submit",value="Submit").click()

You’ll note that I’ve seriously overloaded the dot operator (.); in some contexts, it means “get child object of”, and in other it means “get attribute of”, and in yet a third it means “dereference function attribute of and call function.” Yet as you can see from the example, that’s not tragically confusing. (And yes, “type” is misspelled “typ”, to avoid conflicting with the python keyword type.)

Oh, a fun inner implementation issue: doc.input(name=”username”).style.background.set(”#ffffff”). Here, “Style” has to dereference not to a function, but to value that’s not scalable– it’s a reference to a DOM Style object, so I needed an inner class to be instantiated, that knew what object was being manipulated, in order to manipulate it.

And finally, there are alternatives: doc['input[name=username]‘].set(”user”) will do the same as the first line of the first example. And doc[4] will return a handle to the fourth child element (not node!) of the root document object. This can be really useful when doing things like: doc.table(”#accounting”)[4][4], although to be honest that has a special case handler to skip table headers and go straight for the body.

But what I learned while writing this is that I really do code very much like I write. I wrote a ton of crap, and then when I started to get serious about what I was trying to accomplish, when I started documenting my code, huge amounts of code simply got thrown away. The most common through was “I never did need that.” “I never used that.” “I haven’t implemented that well, let’s take it out and see if we need it later.”

I also seem to thrive in an Extreme Programming environment. I’ve known for a long time that I do that well, and this was no exception; the best development periods were when I had my UI partner looking over my shoulder and the two of us leapfrogged each other’s thinking patterns to home in on exactly what was needed.

For example, the doc[4] started life as a specialized override of __getitem__(), with just a numeric handler for Table and TR objects. He suggseted I push it up into the base Element handler and use it everywhere, and make the Table handler a special case if the Table had a Tbody (oh, and push that logic into the Javascript library to avoid round-tripping the conditional), and I immediately saw the utility of putting a type conditional in __getitem__ so that if you passed it a string you could treat it like a CSS selector.

Anyway, I’ve been having more fun than a programmer should be allowed to have.

At the office, we have exactly three approved programming languanges: C for performance, Python for everything else, and a begrudging tolerance for ECMA-262 for the WebUI team and site design. (Although the docs deployment people get away with PHP, which annoys me to absolutely no end.)

The problem has been that unit testing the WebUI has been more or less impossible in a systematic way in a language that QA has been required to learn. The most useful of all WebUI unit testing frameworks is FireWatir, Firefox Web Application Testing In Ruby. It’s a nifty framework; it talks to a Firefox (or Mozilla) instance over a telnet socket opened up in firefox’s backside (oh, baby, talk dirty to me!).

But it’s written in Ruby, dammit. I don’t want to have to teach my QA team another programming language.

Therefore, the solution was completely obvious: rewrite FireWatir in Python.

I’m not saying I’ve done this. I won’t even talk about what I have done. But for programmers fluent in Python, Ruby, and Javascript, who are comfortable with network programming and can successfully build Mozilla by hand, it won’t take more than 24 straight hours (not “a day,” mind you but a 24-hour work cycle) to port the entire project to Python.

If someone did such a thing, though, what would they call it?

The list of sites to turf is in the right-hand sidebar of the page, and it’s a simple drop-down box (a <select> box). Below it is a list of sites that correspond to one of the four categories, “liberal,” “conservative,” “moderate,” or “other.” When you change the category, the javascript engine goes and fetches a new list for you. Every single time.

The initial download of that page is 610KB, and Firefox considers 503KB of that uncacheable! McCain’s web developers aren’t saving anything by widgetizing another 20KB or so of data, they costing themselves bandwidth and, to the professionals in the audience, they look really stupid.

Rich Internet Application developers like myself make decisions about this kind of material all the time. Repeated downloads of small static blocks waste the viewer’s time, chew up bandwidth, and contribute nothing to comprehension. It’s just bad programming.

For lists like this, the correct solution would have been a single <div> container with three inner <div>s, one for each list, each tagged with an id for the specific category, a class for the javascript to hook into, and a style of display:none. Inside each <div> you’d put a <UL> or <DL> (the latter if you want some additional information, <DD>-type, with each entry, which the McCain people do), and then with an onReady handler hook up the javascript you’re going to use anyway to swap the three divs in and out as needed, with additional javascript to handle showing the <DT> information when whatever event you want to associate with it happens.

Viola’. Two chunks of javascript much smaller, faster, smarter and easier than any ajax call, a little responsible HTML, and some straightforward CSS and that sidebar is perfomant, accurate, and and attractive.

As an extra, if you have firebug installed, go download one of those lists and then run “Inpect Element” on it. That’s the most bloated, overwrought, overstyled, ridiculous post-hoc generated HTML I’ve seen in a long time. It looks like something a Microsoft product would generate.

And finally, the lists have double-click clickthroughs: when you click on the site name, it doesn’t take you to the site. No, it lets you see the <DD> information, which then contains the link to the site. That’s information that should have been contained in a rollover, with a “Show All” feature at the top. But I guess McCain’s people are too busy enjoying their Ajax framework and their animated “please wait” graphic to program responsibly.

Bloated, overwrought, inappropriate emphasis, coming to a conclusion only as a side-effect of appearances: you can’t help but wonder if the whole thing is a metaphor.

This morning I went to examine my calendar only to discover that Windows had “updated” itself sometime in the night and I had to log back in. When I had, I saw the usual array of icons on the left. I scrolled through them until I found the one for “Email,” and, this being vmware and a little slow as images are being pulled off-disk (over NFS, ouch!), I right-clicked to pull up the context menu.

And I couldn’t find “Open.” I’ve been using various operating systems for years. My attentional awareness is optimized for that icon (refer to Scott McCloud’s Understanding Comics, a book which ought to be on every web developer’s bookshelf, for the discussion on how the word is the “ultimate abstract icon”), “OPEN”.

After a second of confusion, I realized there was an entry on the menu, “Read email…”

Thank you, Microsoft, for once again taking a familiar pattern and warping it to your own perverted ends. Everyone knows how to “open” a letter, or a mailbox. Why Outlook has to be different is not beyond me: you’re just trying to ruin the experience for everyone else.

It’s very raw (isn’t everything I write “very raw?”) and it’s missing some functionality, but it’s good enough for me. If it’s good enough for you, enjoy: Muse2Html.py

[ECMA Version 3 (1999), section 11.2.2, page 56]

The production NewExpression : new NewExpression is evaluated as follows:

1. Evaluate NewExpression.
2. Call GetValue(Result(1)).
3. If Type(Result(2)) is not Object, throw a TypeError exception.
4. If Result(2) does not implement the internal [[Construct]] method, throw a TypeError exception.
5. Call the [[Construct]] method on Result(2), providing no arguments (that is, an empty list of arguments).
6. Return Result(5).

[Section 13.2.2, page 86]

When the [[Construct]] property for a Function object F is called, the following steps are taken:

1. Create a new native ECMAScript object.
2. Set the [[Class]] property of Result(1) to “Object”.
3. Get the value of the prototype property of the F.
4. If Result(3) is an object, set the [[Prototype]] property of Result(1) to Result(3).
5. If Result(3) is not an object, set the [[Prototype]] property of Result(1) to the original Object prototype object as described in 15.2.3.1.
6. Invoke the [[Call]] property of F, providing Result(1) as the this value and providing the argument list passed into [[Construct]] as the argument values.
7. If Type(Result(6)) is Object then return Result(6).
8. Return Result(1).

I just wanted to put that somewhere where it wouldn’t get lost.

It also took me a while to realize that Result(N) means “the product after performing the operation of step N.

The new keyword allows you to define objects with prototypes, so that you can have a class heirarchy that doesn’t require external maintenence. I strongly suspect that Doug Crockford’s lecture on “prototypal inheritance” would be edifying here.