Group Access in Twisted

This is a rant -- a positive one. twisted.cred is freaking brilliant. I've had to use it in the past to write my own credential checkers, so I've dabbled a bit. I was thrilled then because of the ease with which I was able to glue systems together. But tonight, I needed to add last-minute support for group access control to a twisted/nevow application and nevow resources that use JSON-RPC. The customer now wants different page views/menus for different classes of user; in addition, they have a new set of RPC

methods that should only be accessible to privileged users.

Typical nightmare situation, when it comes to last-minute tasks, right?

Not with twisted.cred, it isn't. Basically, all I had to do was create an interface for each group that needed to be represented. I then did the following:

• updated the function that instantiates the RPC parent and subhandlers, instantiating the right ones based on the passed interfaces
• updated the avatar realm to choose the correct interface for a given group type
• subclassed the root page for each group that needed a different page

I didn't have to touch the credential checker since it was already getting the group info (I *knew* the customer was going to ask for something like this, even though it wasn't in the reqs).

The interfaces, a few methods (implements/implementer, providedBy), and the amazing functionality provided by twisted.cred -- that's all that was needed. I've never written my own access control code before, and it took less time with cred to actually implement the thing than the "simple" mere configuration that other systems take. Really. It went so quickly and smoothly that I spent the time saved adding some nifty features that take advantage of these changes.

Python-esque Imports in JavaScript

programming :: javascript :: web

Caveat 1: It has been several years since I've been forced to work with
JavaScript. Caveat 2: This has either been done before and considered
stupid or done before and done better. If so, I'm sure I'll hear about
it :-)

And before I get started, I've been meaning to blog about
MochiKit. I've got all sorts of good
things to say about it, but I'm so busy using it that I'm not sure I'll
ever get around to it. Among the many reasons that people rave about
MochiKit, let me say that the first and foremost should be what the
MochiKit team has done most for JavaScript: coding convention. Even
though there are lots of stylistic inconsistencies in the various
MochiKit libraries, compared to JavaScript in the wild, it is a
completely unified whole. Wild JavaScript is generally pure shite.

Back to the topic: the project I am working on right now has multiple
"screens" that are loaded depending on user interaction. Pretty common
fare. But I really didn't want to load all the DOM manipulation stuff
in a series of *.js files on page load. There are WAY to many files for
this. So I wrote importLibrary().

My first attempt at writing this function was to append script tags to
HEAD with the proper source information in it. Which works...
eventually -- the js source just isn't available immediately. So here's
what I did:

     req = getXMLHttpRequest();
     req.open('GET', file, false);
     req.send('');
     js = req.responseText;
     eval(js);

Now, as far as I know, there is no reason to object to the "eval()"
call here, since this is just the same thing (again, as far as I know)
as when your browser downloads the file by itself. This filename is not
parsed from a URL or derived from any human input.

In addition, I wrote a little function for parsing the import
parameters so that

importLibrary('MyProject.ThisSection.ThisScreen')

maps to a file available at an arbitrary (pre-determined per-project)
location off of docroot on the web server.

The import itself has to be done synchronously to ensure that JS code
is available to everything after the called to import. Right now, I
have it doing simple checking to see if the js file has already been
imported, and if so, skips it. I would like to add some kind of "use
queue" as well, where most frequently clicked screens are bumped to the
top (or bottom), and those least visited are pushed off the queue and
then not maintained in HEAD.

This has really enabled me to organize the code for the project in a
sane way.

Now playing:

Glenn Gould - The Art of Fugue, BWV 1080: Contrapunctus IX (a 4, alla Duodecima)

The Joys of IRC

twisted :: python :: internet

And in particular, #twisted. Here's a great little story (and moral)
from Moshe Zadka:

[13:41]<moshez> dreid: did I tell you about the watchdog
[13:41]<dreid> moshez: no
[13:42]<moshez> dreid: oh, man it is awesome
[13:42]<moshez> dreid: ok, so it goes like that
[13:42]<moshez> dreid: there are a bunch of components
[13:42]<moshez> each component has any number of heart-beats
[13:43]<moshez> a heart-beat is a "heart" (opaque string) and a "beat" 
                (a number)
[13:43]<moshez> the heart-strings are sent, as UDP packets, to the EKG 
                port
[13:44]<moshez> the watchdog launches all the components, and then 
                watches the EKG
[13:44]<moshez> if any component has a heart which doesn't beat, it 
                starts fixing the problem
[13:44]<moshez> the first few times, it will shut down all components 
                and bring them back up
[13:44]<Tv> moshez: when does the dog eat the heart?
[13:45]<moshez> if it sees it needs to do that too many times, it will 
                decide "patient is dead" and reboot the system
[13:45]<moshez> if it sees it needs to reboot the system too many 
                times, it will decide "patient is stupid" and stop curing 
                efforts
[13:46]<dreid> hehe
[13:46]<dreid> i like that last part
[13:47]<foom> so stupid is worse than dead, eh?
[13:47]<dash> foom: there aren't any stories about voodoo curing stupid
[13:48]<moshez> foom: yes. you might be able to resuscitate, but you 
                can't cure stupidity

Now playing:

The Bothy Band - Julia Delaney

Nevow + WYSIWYG Editors

nevow :: formal :: javascript

Due to pressing needs of a couple projects, I finally sat down today
and reviewed some of the JavaScript WYSIWYG textarea widgets/HTML
editors. Because of my exposure to Zope and Plone,
Kupu and
Epoz
were the ones that leapt most readily to mind. A quick google exposed
two others that I had forgotten about:
TinyMCE and
FCKEditor.

The nice thing about the latter two is the fact that they can more or
less be used with any web-based application. Kupu is striving for that,
but (as far as I can tell) it's still somewhat of a pain integrating
it. Tiny and FCK have options for integration via simple JavaScript
hooks. My preference is for Tiny, given that it loads WAY faster,
provides exactly what I need, has a code base orders of magnitude
smaller (only kidding a little bit), and has a cleaner look.

I'm a pretty big fan of the
formal
library (formerly know as "forms") by Matt Goodall of
pollenation.
I've used it a fair amount when building Nevow apps and the only
limitation I've personally run across involved trying to get it to work
with cred logins (probably *my* limitation). Today, I needed to add
support for WYSIWYG editors, and it was super easy. I wrote up some
examples on the wiki
here,
but it really just boils down to adding the JavaScript hooks in the
HTML "title" (using stan or *TML templates). The image attached to this
blog post is a screenshot of the "formal" example I put together to
demonstrate functionality. For the curious, here is my set of
TinyMCE toolbar customizations.

It really is the little things, though. Users of the Nevow apps where I
will be adding this are now ecstatic. And to be honest, I'm very stoked
too. It's almost as much fun as MochiKit, but that's for another blog
entry...