[Twisted-Python] Bug involving Interface.pixel, Interface.box, and Method
![](https://secure.gravatar.com/avatar/daf660d6890426570e2e2188f4f7b27e.jpg?s=120&d=mm&r=g)
Here's the low-down of a bug that I can't seem to squash. If you go to one of the pages in my site, ie http://twistedmatrix.com:8010/code , you'll see that the pixel images around the table are referenced as /code/pixel (which doesn't exist). This should be /pixel, but since the request that's eventually being passed to Interface.box() is from /code, it's trying to get /code/pixel. If you'd like to see the code for my site, it's at http://twistedmatrix.com:8010/mysite.py. I'm fairly certain that it's not a bug in my code, but an issue involving both box() and Method. I thought of a few no-good hacks to get around this. 1) I can just have box() reference /pixel rather than /requestpath/pixel, but this obviously won't work for sites whose / isn't an Interface. 2) I can provide a Method.getChild that returns (basically, not literally) ../request, or something like that. Blech. So. I'm clueless. Thanks for any help. -- Chris Armstrong http://twistedmatrix.com/~carmstro carmstro@dynup.net There is a 90% chance that this message was written when the author's been awake longer than he should have. Please disregard any senseless drivel.
![](https://secure.gravatar.com/avatar/e1554622707bedd9202884900430b838.jpg?s=120&d=mm&r=g)
On Tue, 6 Feb 2001, Chris Armstrong wrote: [ stuff about bugs, pixels, and boxes ] This isn't a bug -- since those methods (box, etc) are designed to be used by Interface, it expects that the current page will have a child called 'pixel' that will provide the image support that it needs. Also, this starts to beg the question of creating an actual *good* HTML generation library; the stuff in twisted.web is extremely hacky. However, it does outline a general philosophy that I'd like to preserve, so here you go -- Twisted.Web was not, and is not, designed as a "content" (i.e. design-heavy text) generation tool. It is intended to be used to generate an efficient, distributed interface to stateful Python programs. To that end, it's desirable that whatever HTML generation API comes with it should treat them as program interface elements; wherever possible displaying a traceback if generating one of them fails (this is the philosophy behind .runBox() -- segregating the page into elements both visually and in code). I am open to suggestions as to how to achieve that goal. ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://www.twistedmatrix.com/~glyph/
![](https://secure.gravatar.com/avatar/e1554622707bedd9202884900430b838.jpg?s=120&d=mm&r=g)
On Tue, 6 Feb 2001, Chris Armstrong wrote: [ stuff about bugs, pixels, and boxes ] This isn't a bug -- since those methods (box, etc) are designed to be used by Interface, it expects that the current page will have a child called 'pixel' that will provide the image support that it needs. Also, this starts to beg the question of creating an actual *good* HTML generation library; the stuff in twisted.web is extremely hacky. However, it does outline a general philosophy that I'd like to preserve, so here you go -- Twisted.Web was not, and is not, designed as a "content" (i.e. design-heavy text) generation tool. It is intended to be used to generate an efficient, distributed interface to stateful Python programs. To that end, it's desirable that whatever HTML generation API comes with it should treat them as program interface elements; wherever possible displaying a traceback if generating one of them fails (this is the philosophy behind .runBox() -- segregating the page into elements both visually and in code). I am open to suggestions as to how to achieve that goal. ______ __ __ _____ _ _ | ____ | \_/ |_____] |_____| |_____| |_____ | | | | @ t w i s t e d m a t r i x . c o m http://www.twistedmatrix.com/~glyph/
participants (2)
-
Chris Armstrong
-
Glyph Lefkowitz