Andy Chambers wrote:

I've picked off some of the low-hanging fruit in an effort to make hunchentoot handlers cells-aware. Most of the code so far has just been doing the equivalent of deftk but creating "html" widgets instead of tk ones.

http://gitorious.org/projects/hunchncells

The way this will work I think is as follows:- (most of this is vaporware)

1. request comes in from hunchentoot
2. cells handler gets "root" family object from hunchentoot session

(or creates a fresh one) 3) kick off the propagation by setf'ing the request slot on root 4) an initial response is created from the xhtml slot of the root ...user does something on the browser end... 5) make ajax call to updates service 6) the update handler feeds some new paramaters into the model 5) observers on .kids, and .value log changes into an updates slot on the root 6) the updates are sent back down to the client

Sounds good, tho of course the devil is in the details and I am new to all this interwebby stuff.

Food for thought if it comes up: Cells3 introduced a mechanism whereby observers could queue their output to a client-queue and likewise specify a client queue handler for those cases where custom handling is required. Tk, eg, is a little fussy about the order in which things happen, so observers (who do most of the talking to tk) rather than talking directly to tcl/tk had to queue up their actions along with a keyword used by a tk-specific client-q handler to sort things into the right order.

eg, if you are introducing a new node to the dom in one place and referencing it in another, mebbe you have to make sure those bits go to the browser in that order (create before reference) and you'll need to borrow that bit as well from Celtk.

The updates would be a list of strings representing updates to the DOM. When it gets to the client, it is simply eval'd and hopefully, the page reflects the new state.

Flapjax, OpenLaszlo move over! :)

Here's some other stuff I've been thinking about.

1. In celtk, it seems like pretty much all events are sent from tk to

cells for handling by the widget-event-handle. I think that doing the same for javascript events would be too expensive.

Right, Celtk uses the C FFI so we can pin our ears back and go, LTk does not have that much performance hence access to the event stream.

Perhaps we could classify events into those that need to be sent immediately, those that can be sent periodically (say every 5 seconds), and those that can be ignored. I think even this would be probably not be scalable but I don't work for google so I don't have to worry about that ;-).

2. How do we feed these javascript events into the model? This would

probably be another handler on a different url that listens for events specified as ajax GETs like this...

   GET /events?event=change&id=I034&new=somevalue

It feeds these onto an events slot on the model and returns the

current value of the updates slot mentioned above to the client

I am afraid it's all Greek to me, but if you really need the input lemme know and you can bring me up to speed on the technology.

If this is at all relevant, I have always anticipated a Cells.js support module to make it all go.

kt

ps. I am tempted to mention all this on comp.lang.lisp, mebbe scare up some more interested parties. k