[Twisted-Python] Woven Model extreme pain

[Donovan Preston]

On Oct 3, 2003, at 4:32 AM, Syver Enstad wrote:

> James Y Knight <foom at fuhm.net> writes:
>
>> More ARRRRRRRRRRGGGGGGGH.

<snip>

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:

Widget.generate

Controller.handle

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 
model="foo/bar")

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.
>
>
> Examples:

<snip>

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 
right now.

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 
avoid them.

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.

dp