[cells-devel] another redundant update

[Ken Tilton]

Andy Chambers wrote:
> On Tue, Apr 8, 2008 at 1:23 AM, Ken Tilton <kennytilton at optonline.net> wrote:
> 
>> 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)))))))
> 
> 
> Cool.  I wasn't trying to get you to do all the work but admittedly I
> don't think I'd have come up with something so neat straight away.
> Something similar should work for radiobuttons too.

No work, really. I just took your code and turned it into a template by 
swapping out anything that would vary from use to use, throwing in 
backquotes and commas here and there.

The tricky part is a CLOS issue: I can never remember whether to splice 
in additional initargs before or after the ones the macro wants to 
auto-provide. As I mentioned a while ago, auto is good but complete 
control for the user is also good, so we want them to be able to 
override something like :-type.

You might think a second reference overrides the first. Nope, it is 
ignored. But I always forget between occasions when I am doing this and 
end up doing (describe (make-instance 'xxx :aa 1 :aa 2)) after defining 
the appropriate class to remind myself.

> 
> 
>> 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.
> 
> 
> Extra grouping elements never do any harm and are sometimes required
> for fancy CSS.  All those rounded corner tricks you see in "Web 2.0"
> require the contained elements to be wrapped in at least one div and
> depending on the technique used, sometimes 2 or 3.

Great.

> 
> 
>> 3. Will the top always be a page? Perhaps that is another parameter.
> 
> 
> Probably.  I'll try to think of an occasion where that wouldn't be the case.

Maybe on an ecommerce page there would be a lits of items and for each 
the user has to select "size" or "color"? So the parameter "size" is for 
some sub-node, not the page?

> 
> 
>> 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.
> 
> 
> Sorry.  That bit wasn't working correctly in the full version anyway
> so I need to check that more thoroughly.  As I understand it,
> 
> value: is the initial value for the control
> checked: is a "boolean" attribute
> 
> In html, the mere presence of boolean attributes says that they're
> true.

Madness!

>  I think cl-who is clever about this so if we set it to nil, the
> xml rule should just remove checked entirely from the attribute list.
> In traditional web apps, when a user clicks the "submit" button, the
> notion of "successful" forms is introduced to identify which controls
> should be sent.  A checkbox is successful if it has been checked.
> When its successful, its added on to the request as a (key, value).
> The key is the checkbox's :name.  The value is its value.  On the
> server, you can tell by the absence of exported-only-p that the
> control is unchecked.

The nice thing is that future generations will never have to see this 
unpleasantness, they will think OpenAIR is reality.

> 
> With our fine-grained control of what we're sending back though, we
> may as well just send back "on"/"off" values for our checkboxes (or
> 0/1 whatever).  We can update the value on the js side (in fact, we
> can just ignore the value completely and just decide what to send back
> based on the checked state).

I shall leave this to you. :) Lemme know if you get stuck.

kt

ps. As long as we are discussing Cells or macrology or OpenAIR or Lisp I 
think we should spam this list until you are ready to start a project on 
c-l.net for OpenAIR. I am thinking you need more than git, you want 
mailing list services as well. Or can gitorious do that? Or could 
c-l.net do git? I might ask later, git looks like fun.

k