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

> 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.



Reply via email to