On Thu, 2004-04-22 at 08:22, Harald.Nyman@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,
- We're talking about roughly 2 A4 pages
It will grow.
- 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?