[Twisted-web] Athena DOM manipulation

[Jean-Paul Calderone]

On Mon, 04 Sep 2006 23:59:22 +0100, Phil Mayers <p.mayers at imperial.ac.uk> wrote:
>Is it possible for an athena LivePage to add new LiveElements? To remove 
>them?
>
>The application is a web-based database editor which due to operational 
>requirements has suddenly had a ballooning in the number of fields per HTML 
>page, and the round-tripping of the form submits plus rendering of the 
>extremely large HTML in one large block is actually now causing operational 
>difficulties.
>
>Something like:
>
>+-(main)-------------------+
>| field1: ______           |
>| field2: ______           |
>| checkbox: [__]           |
>|                          |
>+-(subitems)---------------+
>| key | name | dom |       |
>+-----+------+-----+-------+
>|     |      |     | [del] | << this is a 3-textbox row for each subitem
>+-----+------+-----+-------+
>| [Add new subitem?]       | << this is a
>+--------------------------+
>
>
>...with maybe ~60 and climbing rows of subitems. I can handle the initial 
>loading of the page taking a bit of time, but a user might want to add, 
>change or delete ~10-25 rows of subitems each time they visit the page, and 
>the round-tripping is genuinely detrimental.
>
>Can you do something like returning a LiveElement from a callRemote? Or can 
>you somehow create (in a supported fashion) a server-side LiveElement, 
>return the ID/html/whatever from the callRemote'ed method, and then run the 
>client-side widget creation JavaScript, supplying the ID?
>
>Is this just plain a bad idea? Should I somehow make the entire list of 
>subitems a single widget (less attractive, because the in-built client and 
>server-side demuxing of the LiveElement -> row is attractive)

Hey Phil,

One can indeed add new LiveElements to an already-rendered Athena page. The
simplest way to go about this is to just return the LiveElement from a
method.  The Element will be serialized in the same manner as one included
in the initial page render and arrive as an xml string given to the callback
of the Deferred returned by callRemote on the client.  The xml string can be
added to the page using Divmod.Runtime.theRuntime.{set,append}NodeContent.

Now, this is pretty nasty.

I would much rather this work in a very similar manner, but with the
important difference that the client should receive an actual Widget
instance, rather than an xml string.

I currently have no plans to implement this, but it is the way I would
ultimately like Athena to work.  In order to future proof Athena
applications, I would recommend explicitly serializing the Element when
returning it, rather than relying on Athena to do it for you.  This will
produce exactly the same behavior as I described above, with the difference
that when Athena changes, your application won't suddenly begin receiving
Widgets where it expects xml strings.

Flattening an Element is straightforward: simply pass it to
nevow.flat.flatten.  In order to exactly replicate Athena's treatment, you
will also need to wrap it in a div with the xhtml namespace.  In other words,

flat.flatten(tags.div(xmlns="http://www.w3.org/1999/xhtml")[obj])

Of course, if anyone would care to implement the change I described above,
I would be delighted.

Hope this clears things up,

Jean-Paul