Andy Chambers wrote:
On Tue, Apr 8, 2008 at 1:23 AM, Ken Tilton kennytilton@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 (,@topargs) (mk-label (,@label-args :for ,(symbol-name attribute)) ,label) (mk-input (,@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?!!! :)
Observe that parameters for any node must be in their own list.
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.
- 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?
- 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
Ken Tilton wrote:
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.
I just thought of a mnemonic: the initarg list is probably being treated as a plist, so the first of duplicates is the only one seen.
kt
-
Ken Tilton