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

[andy]

Ken Tilton writes:
 > Ken Tilton wrote:
 > > Awesome subject. :)

:-)

 > >> 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?

Yeah.  I'm working on that now so I'll let you know later this goes.

 > > 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>).

How about xref, or just ref.  I don't think the name matters really
much since xml has namespaces to avoid collisions.  We just put it in
the http://openair.net/ (or whatever) namespace.

I'm going to read through the previous stuff you've posted about
lookups since I'm still not clear about how it would work.  Here's my
understanding at the minute.  Does it sound ok?

All the actual xml would have to be stored somewhere, presumably a
javascript associative array.  Then, whenever something is sent to the
browser, we find all xlookup elements and replace them with their
associated content.

 > > 
 > 
 > 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.

Just to make sure I'm not missing anything, is the comparison below
what you consider the difference to be?

<xlookup ref="s123">

Here's the equivalent

<li id="l123"><span id="s123">progv</span></li>

 > 
 > 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.

No problem.  We should do it right.