I discovered a bug in the released Nevow that I am using for the trigger configuration pages in Cinemon. The bug is fairly simple, when a user returns to a page (loading it from their browser's cache), the server has not rendered the page for this loading. Because Nevow constructs the client connection object during rendering, this meant that a user returning to a page wouldn't have any of the callbacks required to make the page "live" registered.
Well, as you might expect, the easiest way to solve that problem is just to disable caching of the page, and that's exactly what Nevow has done in SVN. Great. Except that they've also deprecated the "handler" objects which allow you to construct dynamically-generated live-pages.
Spent a bit of time reviewing the two mechanisms that replace the handler objects. Neither is appropriate for doing nested tree-editing controls. One is defined as methods on the page object, the other is single-use callbacks. When you construct a live sub-form you don't want to have to inject handlers into the main page, nor do you want to have the form active solely for the first event that it generates.
So, I created (and posted to the twisted-web list) a mechanism that gives the bulk of the functionality of the handler objects (at least, everything we were using). I also reworked some of the mechanisms inside the LivePage object set so that it's easier to work with LivePages (in particular, you can access the current ClientHandle object in any rendering method).
The amount of boilerplate required to do the overriding was somewhat off-putting. LivePage uses a set of contained objects to provide its functionality. When you want to override a low-level object like a ClientConnection you wind up having to subclass 4 or 5 classes just to override their declarations of which lower-level class is to be used for constructing the contained objects.
I also spent around an hour this morning wrestling with the balky phone for Cinemon. I think I've figured out all the kinks but wow, it is a truly non-intuitive user interface in almost every way. The voicemail link doesn't even suggest that you can get to your messages, it just launches into the please-leave-a-message greeting (you have to press # during that to get to your messages). The address book is just baroque. Oh well, I'll likely only use it for answering incoming calls anyway.


Comments
2010-07-25 14:02
> and would have no Trac integ ration The trac-bzr plugin[ 1] seems to provide good integ ration between bzr and t [...]
2010-07-13 21:47
I've always been fascinated wi th the Asterisk AMI interface. So much so that I married tha t fascination with the [...]
2010-07-03 21:32
Yes, only references in dicti onaries are replaced, so hold ing references in lists, tuple s, etceteras keeps them alive.
2010-07-03 11:18
They hold references to remove and install?
2010-06-24 08:34
There's higher-level objects w hich are tracking what is repl aced (the actual Mock objects) . They hold references [...]
2010-06-24 08:23
I haven't tried it, but it see ms to me like this approach ha s one fundamental problem: If you replace all refs o [...]
2010-06-24 08:22
That's the "magic" that made m e go "ooh shiny"
2010-06-24 06:03
That's even more evil than the mock patch decorator...
2010-06-06 18:33
blush Oh.
2010-06-06 11:07
That's what the module does (a utomatically), but on a per-te st-run basis, and only for the process being tested (i [...]
2010-06-06 02:43
Maybe I'm missing something im portant here, but why not just write small scripts to mimic whatever dangerous utili [...]
2010-06-05 15:17
I thought about stubbing out t he python call to the process in the current process, but I want something which stu [...]
2010-06-05 14:47
Hmm... if Mock isn't flexibl e enough to handle mocking pro cesses adequately then I'd lik e to know how it could b [...]
2010-05-19 10:27
Hey, maybe it's a stupid new bie question, but where and ho w exactly should the patching of the core take place? [...]
2010-05-04 14:36
I used Qemu and VirtualBox pre tty extensively back when I wa s working for the OLPC, but mo st of the stuff we were [...]