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

[Ken Tilton]

Ken Tilton wrote:
> 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>).
> 

It occurs to me that this apropos example would benefit another way from 
something like xlookup. Suppose can only guess a chunk of name that is 
very common, so there are a lot of matches. That's OK, now they just 
click various check boxes that limit the matching. But each time they 
click on a selection criteria a round-trip is needed to ask Common Lisp 
which symbols are, say, exported. Suppose a third are.

Without xlookup, the xhtml for that one third must be resent. With 
xlookup, the parent just resends itself listing so many terse little 
xlookup tags. GC on the client side could be handled during "not-to-be" 
processing.

When that is working we can look at implementing this bit wholly on the 
client side, with Cells/js.

jes thinkin out loud.... but it does make me less interested in 
exploring other ways to fix the edge case.

kenny