[cells-devel] Booyah!! openair off the ground

[Ken Tilton]

Awesome subject. :)

Andy Chambers wrote:
> So I put kenny's code into master and made it work with the
> hunchentoot server.  I changed the example a little so that it only
> makes requests when focus is removed from the text box (hit tab or
> click somewhere else in the window).
> 
> I just wanted to see it working before reading up on aserve's
> webobjects and adding support for them so kenny can see this in
> action.

OK, so I should wait?

> 
> Admittedly, it does seem a little buggy.  If the apropos-list is too
> large, it seems to hang the server (although refreshing the page and
> starting again is allowed because hunch just starts a new thread).
> 
> To try it for yourself...
> 
> If you haven't cloned the repo already...
> 
> $ git clone git://gitorious.org/hunchncells/mainline.git openair
> 
> ...otherwise update your repo
> 
> $ git pull origin
> 
> ...then after adusting your asdf locations accordingly...
> 
> (require :openair)
> (start-server :port 8080)
> (reload)
> 
> then point your browser to http://localhost:8080/apropos
> 
> type something into the text box and hit Tab.

I have been thinking about that edge case with a grandparent and 
grandchild changing but not the parent. One thing to do (besides what I 
think we should do, viz. xlookup) would be to extend cells to allow 
something like, ok, this reference to another cell is a dependency, but 
make it a lazy (non-propagating) dependency. This, btw, could be 
achieved by recording the other cell as /used/ but not recording me as a 
user. Which makes me wonder if a synaptic cell might not do, one that 
simply never says "yes" to the question "should this new value be 
propagated?". The key here is that we want this to be 
dependency-specific. If it were rule-wide, we already have lazy cells. 
But the only dependency we want lazy is when we go after a child node's 
xml. It would be cool if a synapse Just Worked, but it would be more 
efficient to extend Cells to have lazy dependencies.

Another approach would be to change the html generating macros to return 
functions which will when invoked generate the XML, including child XML 
by calling /those/ nodes xhtml generators. Deferred evaluation and all 
that. Then when the grandparent rule got reran and a new function 
generated, when that got called it would call its child's function (the 
parent in the kid-parent-grandparent use case at hand) and it would call 
the kids and get the latest xhtml. I guess this is like the Lisp trick 
of letting us change a function at runtime and then have the new version 
called by an old and un-reompiled caller, the function being resolved at 
runtime.

And then the final approach is the xlookup thing, really deferring 
dispatch until /browser/ run-time.

btw, those were presented in increasing order of superiority. :) The 
first might be easiest and I will explore it a little now, the second 
might be tough or might not, and I have no clue how hard xlookup would 
be (but I am pretty sure that is not a good name for it <g>).

Anyway, looking forward to the aserve version.

Congrats!

kenny

kt