Andy Chambers wrote:
On Tue, Apr 8, 2008 at 1:23 AM, Ken Tilton <[EMAIL PROTECTED]> 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?!!! :)
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
_______________________________________________
cells-devel site list
cells-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/cells-devel
