[cells-devel] family hierarchies

[Andy Chambers]

On Wed, Mar 26, 2008 at 1:57 AM, Ken Tilton <kennytilton at 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