On Wed, Mar 26, 2008 at 1:57 AM, Ken Tilton kennytilton@optonline.net wrote:
Andy,
Food for thought: I just noticed a recent email from Peter Hildebrandt who had likewise wished he had time to do what you are doing. Peter struck me as very solid (as do you <g>). Sounds like things are going well for you, so you might mention Hunchncells on cells-devel or even c.l.lisp when you are ready for company, or we could just try Peter and/or Edi Weitz directly.
I thought I had but looking back, it does seem that some of these exchanges have been sent directly to you Kenny. Sorry about that, I didn't mean to exclude anyone.
So for the list....
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
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.
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. 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
-- Andy