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