[Twisted-Python] LivePage Hello World

[Donovan Preston]

On Wednesday, May 21, 2003, at 06:53 PM, Eric Holm wrote:

> I'm trying to get a simple LivePage script going,
> and no luck so far.

Cool! LivePage is not really ready for human consumption yet, but it's 
*really* *really* close.

>   I started with the example on
> howto/livepage.html, and added enough bits to get
> it to run (the only surprise was that Foo.setUp()
> needs a 3rd, unused argument), and I've attached
> it at the end of this mail.
>
> When I view the source in the browser, there's
> a bunch of Flash stuff at the bottom (so *that's*
> how "Javascript opens Socket to server" works...),

LivePage is really two different things: The InputConduit and the 
OutputConduit.

The InputConduit is responsible for shuttling events from the client 
(web browser) to the server (Twisted). The InputConduit is just a 
simple IFrame and some associated javascript which translates from 
JavaScript events placed on a Widget using addEventHandler to a HTTP 
GET request (in the IFrame) with the relevant pieces of information:

1) The name of the client side event ('onclick', 'onchange')
2) The id of the target node ('woven_id_12341234', 'myId')
3) The arguments to pass to the event handler (Usually none.)

When I originally wrote the server-side component that listens for 
events from the InputConduit, I wrote it asynchronously; the HTTP 
Request would generate an HTTP Response immediately (with no 
interesting information in it) and the server-side event handler would 
be fired one reactor iteration later. Which brings me to...

The OutputConduit is responsible for shuttling events from the Server 
(Twisted) to the Client (web browser). When a Web Browser has visited a 
LivePage and created a tree of MVC objects and a DOM tree, LivePage 
stores the root of this (the LivePage instance itself) on the 
server-side session object. Then, at any time, a server-side event may 
cause a Widget to re-render itself and send the updated HTML fragment 
to the browser. The OutputConduit then uses some simple javascript in 
the browser to replace the old node (which it locates by id) with the 
new, updated HTML string.

The OutputConduit is interesting if you have applications where 
server-side events are generated without the user actually interacting 
with the web browser. For example, in the NewReality web client, one 
user may log on using a web browser while another player may telnet 
into the game server. The other player, typing commands into a telnet 
window, will generate events which are not directly initiated by the 
player using the web browser. In this situation, the OutputConduit is 
useful because the server may direct the web browser to update the HTML 
the user is seeing without the user actually doing anything, such as 
refreshing the page.

To get to the point, I realized that if you are interested in using 
LivePage to do normal, DHTML style partial-page refreshes in response 
to user events (mouse clicks, dropdown selections, mouseovers) then the 
OutputConduit is not required at all. Since the user initiated an HTTP 
Request by invoking the client side event handler (onclick for example) 
we can piggyback on the HTTP Response any JavaScript commands we want 
to execute in response to that event. We do this by waiting for the 
event handler to fire, gathering all JavaScript commands which were 
sent to the OutputConduit while we were waiting into a list, and 
rendering them out in a single <script> tag in the HTTP response to the 
event.

This is ultimately where LivePage is going; it will allow LivePage 
penetration into browsers that will not be able to open a persistent 
socket to the server.

But all that has nothing to do with your problem.

> but when fooHappened() runs, I get a
>
> CACHING [<twisted.web.woven.utils.Script instance at 0x00F3F300>]
>
> message.  The corresponding comment in utils.py
> talks about a conduit not being connected yet,
> but I've no idea how to initiate a connection.
> Anybody have any idea what I'm missing?

The example you pasted was an example of what the OutputConduit is 
supposed to let you do. The OutputConduit is implemented using a Flash 
movie that opens a raw socket to the Twisted server (on IE Win; on 
Mozilla the implementation will probably be different; on other 
browsers it will probably use a polling technique to periodically check 
for new content)

The Flash movie needs to talk to the server using a special (extra 
silly) protocol. The magic incantation to get your Twisted server to 
listen on this port and talk this protocol is this:

mktap web --path=/foo/bar --flashconduit=4321

Patches against the documentation in CVS would be gratefully accepted. 
If you'd like to talk more about LivePage and where it's going, you can 
find me on irc pretty regularly as fzZzy.

If enough people keep bugging me about it, I will write another example 
which only uses the InputConduit, which is a technique that has proven 
to be far more reliable and cross-browser in the past month. All of 
this stuff is going to mature really soon, really fast :-)

Donovan