[Twisted-Python] Woven Model extreme pain
dp at twistedmatrix.com
Fri Oct 3 12:49:27 EDT 2003
On Oct 3, 2003, at 4:32 AM, Syver Enstad wrote:
> James Y Knight <foom at fuhm.net> writes:
>> More ARRRRRRRRRRGGGGGGGH.
I apologize. Woven's Deferred support is only very lightly tested
because every application I have built in Woven has not been very
deferred-heavy, and when I have had to use Deferreds I am able to use
them because I wrote the code.
Writing code which handles Deferreds in every conceivable situation is
very difficult because it makes the code more verbose and less linear.
This is mostly due to Python's lack of a block syntax, and there's not
a lot we can do about it. Woven supports deferreds by checking for
Deferred results from two woven APIs:
If a Deferred is returned from either of these functions, Woven will
not recurse into the DOM branch which the Widget or Controller was
handling until the Deferred has fired. Woven will continue rendering
the rest of the page, and when it gets to the end, if there are
outstanding Deferreds, it will not send the page to the browser until
these Deferred tasks have completed.
When a Deferred fires, Woven will then recurse into the DOM branch
related to the Deferred. If a DOM node below that one contains a
directive which produces a Widget or Controller which returns a
Deferred, the process will be repeated.
This is basically how Woven's Deferred support works.
The first thing Widget.generate does is call Model.getData. If
Model.getData returns a Deferred, it will add a callback to it which
continues the Widget rendering process when the Deferred has fired.
This is why the layout described below by Syver is required. There is
no support for Deferreds in lookupSubmodel (the code which parses
Also, the IModel interface was designed about a year and a half ago, at
the very beginning of DOMTemplate and WebMVC development. It turned out
to be a fairly cumbersome API to use (one which only existed because of
python's lack of the concept of a handle) and after Glyph wrote
submodelFactory and MethodModel, I have mostly relied on using that.
> I've also been down this road James. You can't tunnel through
> deferreds in the submodel path, and you have to specify a view for the
> deferred system to work.
All of these examples and explanations seem correct. The fact that such
an elaborate dance is required I would consider a bug, but
unfortunately I don't have a lot of time for core woven development
Woven was developed over the course of a year, in my spare time, while
I had a day job.
Now that woven is stable enough for me to use, I have slowed
development on it because it enables me to get my paying work done, and
a lot of the quirks in the API don't bother me because I know enough to
While I believe the core ideas behind Woven are very good, a lot of the
implementation details are more complicated than they should be (as you
have noticed). I would very much like to do a ground-up rewrite which
would simplify the way things work greatly while still supporting the
best ideas from the current Woven and as much backwards-compatibility
as is feasible.
I don't have the time to do a ground-up rewrite right now and still get
paid to do my regular, day job.
Since woven is now good enough to develop very large, complicated web
applications with, other people have started showing far more interest
in it. Unfortunately, not everyone has the experience with the internal
details of Woven to know what to try and what to avoid. Probably the
best way to proceed in the short term is to come up with some sort of
"Best practices" documentation which describes how best to get your
work done with Woven while avoiding pain.
More information about the Twisted-Python