[cells-devel] Re: How do I do this in JS?

[Ken Tilton]

Andy Chambers wrote:
> On Fri, Apr 11, 2008 at 11:28 PM, Ken Tilton <kennytilton at optonline.net> wrote:
> 
>>Instead of using gensyms to name (ID) interesting fields (not DIVs) I want
>>to use their names, and do so as a path down from the page, so the id for
>>the term input element would be, eg, "apropos.term" or "apropos/term". Then
>>the Lisp-side tree of instances becomes its own dictionary (no need for
>>mirroring slots on the page instance) and then we'll never have a problem
>>with duplicates -- well, if we have a list of identical structures we'll get
>>into a subscript as well, so how would I encode that? Suppose instead of
>>just listing matches each match contained a checkbox to indicate (I don't
>>know) show CLHS entry and then boom they hit enter and multiple entries
>>appear. Well, they need the checkbox to have  a path:
>>apropos/match[42]/show-clhs. Is this where we do "apropos/match.42/clhs" as
>>an ID? I guess I am asking what are the limitations on the id name
>>characters.
> 
> 
>>From the spec...
> 
> ID and NAME tokens must begin with a letter ([A-Za-z]) and may be
> followed by any number of letters, digits ([0-9]), hyphens ("-"),
> underscores ("_"), colons (":"), and periods (".").
> 
> I hadn't actually noticed this before and assumed that anything would
> be ok but went ahead and checked.
> 
> However, this might not matter so much because you can do the thing
> you want with jquery selectors and filters.  Instead of a slash, you
> use ">", and instead of [42], you use :nth-child(42)
> 
> apropos/match[42]/show-clhs  would then be
> $("#apropos > #match :nth-child(42) > #show-clhs)

Cool. Maybe I can leave this idea to you to implement? The idea would be 
to have a path slot on every node that for things which wold never 
change was nil and for anything else searched up to the first parent 
with a path and used that plus the symbol-name of its own :md-name which 
can be coded as a Lisp symbol such as 'term or :term (formatted into a 
JQ-acceptable selector as a string).

One instance can reference another with (fm-other :term) or (fm^ :term) 
if the node is not a child (I can clean up all that whacky inter-model 
referencing syntax like fm-other and dm^), the only one who has to worry 
about the JQ names on the Lisp side is the bit that pipes things over to 
the browser and handles the (now) POSTs.

I think widget values can be handled as usual in Cells apps: if it is an 
input field, just say c-in or c-input or c?n. We will only get POSTs 
from input fields, and Cells will allow those to be setf'ed when they 
come in. The page can have an equal hashtable to speed location of a 
CLOS instance given its JQ ID. An observer on the JQ path can stuff this 
dictionary, or just have the rule itself do it before returning the value:

    :jq-selector (c? (let ((n (symbol-name (md-name self)))
                           (sa (jq-selector-above self))
                           (s (if sa (conc$ sa " > " sa) n))))
                       (setf (gethash s (jq-dict (u^ web-app))) self)
                       s))

Something like that.

> 
>> This may be easier than I thought!

I was feeling the caffeine, now I am not. <g> Better you than me if you 
like where I am going with this.

My one question is the same we had with cl-ode -- observers do not know 
which way a value is going. Observers now get passed the Cell (a very 
recent change) so we can use that: only ruled cells are headed outbound. 
I am just not sure that holds up -- what of we have an input Cell 
reserved for setting in reponse to things happening on the server? Well, 
we could say those still do not get propagated out to the browser -- 
those should be slots on the model, not widgets in the DOM. If we want a 
widget in the DOM to reflect that value (yes, this feels right) we just 
have a widget with a rule that says:

     (mk-text (c? (server-load (u^ web-app))))

Well, in that case I guess we would have a server instance as the parent 
of the web-app (remember when I said fm-top might not hold up?) but you 
get the idea.

And even if this input=inbound, ruled=outbound breaks down we have the 
trick we are doing with cl-ode: simply flag the cell itself for direction.

Hmmm, pardon the rambling, but we do have c?n slots. They run whenever 
something global changes to provide a default the user can override by 
typing, but meant to be re-defaulted if they go back and change this 
overarching other parameter. ie, I have changed the item selection so 
the size and color get re-defaulted, I am starting over.

So this would be a two-way slot... it would mostly work except that the 
observer on xhtml will see a ruled /and/ input cell and not know if it 
should push it onto the updates.

Hmmm. This is to be expected, we are once removed from the action. The 
first thing that pops into my head is a second dictionary, this time 
keying the jq selector to the value we know is over on the client side. 
The observer on xhtml can simply check that the new-value is not already 
on the client side. When we get posts, the first thing we do is record 
that that value is already on the client-side, before injecting the 
value into the Lisp model.

Speaking of which, I guess inputs will come over one at a time as you 
have things set up, but if you think you'll ever get into bundling them 
up and sending over multiple inputs, we should apply another trick from 
cl-ode and control propagation (so multiple setf's look like one to the 
model).

whew. I would gone back and edited all that but it may help for you to 
see my thought path (and maybe something in there sounds better to you 
than where I ended up).

Man, you jumped in at the deep end, eh? :)

kt

ps. I CCed Peter H because he is the mover behind cl-ode and I thought 
he'd enjoy seeing the cross-pollenation. k