[cells-devel] family hierarchies

[Ken Tilton]

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