Andy Chambers wrote:
On Fri, Apr 11, 2008 at 11:28 PM, Ken Tilton kennytilton@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