[cells-devel] another redundant update

[Ken Tilton]

Andy Chambers wrote:
> Hi,
> 
> This was mentioned a while ago and is causing a problem now.  When an
> ajax request comes in, one of the things that gets updated is the
> input value.  For example...
> 
> old: <input name="term" value=""/>
> 
> ...user types in "progv" and hits TAB
> 
> new: <input name="term" value="progv"/>
> 
> We want the model on the server to update itself to reflect this
> change but we don't need to send it down to the browser because the
> browser already knows.  The problem this is causing (and this is
> something we'll need to take a mental note of for the future) is that
> the event binding for the input element is lost when that element is
> replaced.  That means any actions after the first don't trigger an
> ajax request.
> 
> We could rebind the event on the new element but I think its better
> not to send it in the first place.
> 
> I think this would apply to all UI elements so if that's the case, the
> solution is probably to filter updates containing these elements the
> same way that ascendant and redundant nodes get filtered in the code
> below.
> 
> 				  (let ((updt (loop for (h . xh) in (updates self)
> 						 unless (loop for (h2 . nil) in (updates self)
> 							   thereis (unless (eq h h2)
> 								     (when (fm-ascendant-p h2 h)
> 								       (trc nil "suppressing redundant" h :seeing-ascendant h2 (id h2))
> 								       t)))
> 						 collect xh)))
> 
> I've pushed a new version out to the repo but haven't dealt with this
> problem yet.
> 
> Another thing you might notice if you look at commented out code in
> the example is that the radio button at the bottom seems a bit
> verbose.  Radiobuttons could probably do with a layer on top providing
> a nicer way of creating them.

Here is what I did for the exported-only checkbox (untested):

(defmacro mk-checkbox (label attribute &key top-args label-args input-args)
   `(mk-div (, at topargs)
      (mk-label (, at label-args :for ,(symbol-name attribute))
        ,label)
      (mk-input (, at input-args
                 :name ,(symbol-name attribute) :id ,(symbol-name attribute)
                 :-type "checkbox"
                 :checked (c? (,attribute (u^ page))) ; parameterize?
                 :value (c? (,attribute (u^ page)))))))



And then you can just do:

    (mk-checkbox "Exported Only" exported-only-p
        :top-args (:one 1 :two 2))

And to think they banned even a preprocessor from Java. :)

Notes:
0. I mentioned first the idea of having a 'watched-parameter' slot on 
the checkbox. Above macrology lets me achieve even more succinctness 
without complicating the checkbox implementation which stays as minimal 
as possible. Who does not get macros?!!! :)

1. Observe that parameters for any node must be in their own list.

2.  I added a common parent (an extra mk-div) but hopefully that is OK, 
seemes right anyway. If not, I have a work-around in mind, but macros 
only emit one form so it would take (probably) a "flatten" call ... 
hmmm, I suspect I am being daft: do these things end up going thru a 
the-kids form anyway, which would flatten any list so the outer mk-div 
could just be (list...)? Probably.

3. Will the top always be a page? Perhaps that is another parameter.

4. I started with an initial-value parameter then realized that is being 
set at the page level. Then I noticed both checked and value mirroring 
that. What I believe I have done (check Celtk) is have an intial-value 
slot whose observer sets the parameter of whatever node is being 
controlled (here the page). Actions on the checkbox likewise set the 
parameter of the controlled node. Then the checkbox value (as you have 
it) watches the parameter, but we at least author the parameter 
completely (including initialization) from the authoring of the 
checkbox. But I can see it going the other way, with the checkbox being, 
say, an optional interface to a page value that would possibly be 
maintained/originate elsewhere. Anyway, I am still curious about the 
checkbox/value redundancy.

kt