Hi Alex,
> 1. (default .. NIL) has no effect, (off *Radio) might be more
> appropriate.
I still don't have all those picolisp functions under my skin :-(
Thinking about it though, this line is probably unnecessary because
*Radio is never used as a global variable but only dynamically bound
while a form is rendered, so it does not have to be "declared" in
picolisp.
> But the actual problem I see is using a global variable. The
> difficult question is *when* to clear that variable, so that it
> works also when the page is reloaded (possibly with a different
> status and layout), when the browser back-button is pressed, or
> during JavsScript postings.
Sorry for confusion. It is not really a global variable. I should
have given a better example of how it is supposed to be used:
(let *Radio NIL
(form NIL
...
(gui '(+Radio) "group1" "value1a")
...
(gui '(+Radio) "group1" "value2b")
...
(gui '(+Radio) "group2" "value2a")
...
(gui '(+Radio) "group2" "value2b")
...
This way it should work as the only time when *Radio is important is
when a form is being built.
I imagine that if +Radio became part of picolisp code, setting *Radio
to NIL could happen inside the form function and people would not have
to worry about it.
> I think the right way to go would be to have '1st' be the "main"
> component of that radio group, where you can pass an offset like -1,
> -2 etc. in the 'T' method. Each +gui component has an 'id' property
> that can be used for such arithmetics (so you don't have to use
> (length (get *Top 'gui))).
1st is the "main" component of that radio group actually. Except it
currently holds more information, like the whole thing returned by
(assoc Grp *Radio).
I did not know about the id property and I am not sure what does it
contain exactly. If it contains the number which is rendered in html
in the name attribute as <id>: name="*Gui(+<id>)" then 1st could be
directly the first gui radio button in the group, its id property used
for html rendering and (length (get *Top 'gui)) could be dropped off
the *Radio assoc list.
> 2. Why do you distinguish in the 'show>' method between directly calling
> '<radio>', and a "hand-made" version?
>
> > (ifn (: 1st)
> > (<radio> "Var" (: xval) (not (able)))
> > (prin "<input type=\"radio\" name=\"*Gui(+"
> > ...
>
> Is there some subtle difference?
It is very important, because all radio buttons in one group must have
the same 'name' attribute (otherwise a browser would not know they
belong to the same group). I simply reuse the name attribute of the
first radio button in the group. I have to render the radio input
element manually for all radio buttons except the first one because
<radio> does not do the right thing there.
Cheers,
Tomas
--
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
