[Twisted-web] Re: Twisted & legacy code - Unorthodox? Opinions wanted

Alex Levy mesozoic at polynode.com
Thu Apr 22 10:24:02 MDT 2004


On Thu, 2004-04-22 at 08:22, Harald.Nyman at astrazeneca.com wrote:
> What's described could be a creative approach to dealing with legacy code,
> but it could also be an ugly hack, and I would really benefit from the views
> of you gurus as to whether this looks like a good/acceptable/bad way to use
> Twisted. (If 'bad' - any immediate suggestions? :))

Certainly.

> Creating the request in the browser:
> All links in the page are modified to NOT trigger a GET/POST, but use
> javascript to
>  - scan form input (<INPUT>, <SELECT>, etc) and build formInputDict ("{name:
> value, ...}")
>  - create a similar representation of the cookies, as cookiesDict
>  - send the "::"-delimited string using a small applet

Unless you are being _very_ selective and _very_ careful in how this
dictionary is formed and interpreted, it seems like this might open up
unwarranted vulnerabilities.

> The browser
>  - receives the generated HTML string through the applet
>  - parses the cookies
>  - displays the HTML, using document.write

Yikes!

> Is this really a valid way to use Twisted?

I would say any use of Twisted is a valid use, but that doesn't mean
it's the best way to leverage the library's real strengths.

"Luke, if only you knew the power..."

> Will it scale? Will it work with future Twisted versions?

Probably, but again, you're not really taking advantage of all the
flexibility and modularity that Twisted offers. You're force-feeding the
server in order to squeeze out some performance benefits, and doing so
in a way that (to me) seems destined to become a developer's nightmare.

> It can't be used through a firewall.

See below for an application design that _can_ go through a firewall.

> We don't want to rely on and maintain home-written javascript.
>  - Good point. However,
>    1) We're talking about roughly 2 A4 pages

It will grow.

>    2) The javascript to handle form input & cookies is meant to be general,
> and once it's validated, we should not need to touch it much.

Unless security issues come along. And they will.

> We can't do unit tests on the javascript.
>  - Correct. See previous point.

False. Unit tests are entirely possible in Javascript. Whether you
actually _want_ to do them is a different issue. Hint: you don't. :)

You should take a look at how Nevow <http://www.nevow.com/> has
implemented its Freeform module. I'm not saying you need to port your
entire app to Nevow (though it is worth considering), but I think you're
trying to do roughly the same thing. Maybe by emulating some of Nevow's
design decisions, you could get equal performance benefits with a lot
less Javascript magic. An example query:

1. You have a Twisted server running, which serves up web pages. For
example, going to /tasks will show you your task list for today. (I'm
pretending I know anything about what your web app does.)

2. The HTML code for /tasks renders a form, "foo", with a checklist or a
bunch of text fields or whatever else you want.

3. You type in some fields, change values, uncheck stuff, whatever.
Click the Submit button, and it sends a POST to /tasks/formpost!foo.

4. Your Twisted server, receiving this POST, attempts to find the Python
object responsible for handling the URL /tasks/formpost!foo:

 a. First it finds "/", your site root, and asks for "tasks".

 b. Next finds "tasks", which is your TasksPage instance (or something
like that). Twisted asks the TasksPage instance to find a child named
"formpost!foo".

 c. Your TasksPage says, "AHA! I recognize this! It's not really
requesting a separate page. That weird URL tells me to interpret the
form data, modify some internal state or business objects, and then go
right back to the tasks page where I started. Done!"

5. Profit.

This is, with a _lot_ of technical detail missing, what Freeform is all
about -- designing a process for designing objects for which forms can
be automatically rendered and interpreted, with minimal effort on your
part. I'm already using it to design a non-fancy CMS that will power my
web page very soon.

Nevow is currently undergoing some serious reorganization, and after the
refactor, Freeform will have gone from a really cool gizmo to a very
strong, flexible engine. If you're interested in using such a framework,
I suggest getting more information from those developers more closely
involved in the process. (If you don't have an aversion to IRC, the best
place to get the latest scoop is in #twisted.web on irc.freenode.net.)

However, if your team isn't comfortable working with a platform that is
still going through serious changes, just implementing the above process
on your own would, in my view, result in a much better platform for web
development than the Javascript/socket mess you've suggested above.

One man's opinion, writ large. Anyone else?

-- 
Alex Levy
WWW: http://mesozoic.geecs.org/

"Never let your sense of morals prevent you from doing what is right."
-- Salvor Hardin, Isaac Asimov's _Foundation_
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://pyramid.twistedmatrix.com/pipermail/twisted-web/attachments/20040422/e701716c/attachment.bin


More information about the Twisted-web mailing list