On Sat, Aug 23, 2008 at 01:12:48PM +0200, Alexander Burger wrote:
> Still it all hangs on the JavaScript problem ...
Finally, I think I've got it :-)
In "lib/form.js" the following must be inserted at line 120:
else if (fld.type == "radio") {
fld.value = val;
fld.checked = txt[i++].charAt(0) != "";
}
Then the following implementation of +Radio seems to work:
################################################################
(class +Radio +field)
# grp val lbl
# (grp val [lbl])
(dm T (Grp Val Lbl)
(super)
(=: grp (if Grp (field @) This))
(=: val Val)
(=: lbl Lbl) )
(dm show> ("Var")
(showFld
(<radio>
(cons '*Gui (: grp id))
(: val)
(not (able)) ) ) )
(dm js> ()
(pack
(ht:Fmt (: val))
"&" (= (: val) (val> (: grp)))
(unless (able) "&=") ) )
(dm set> (Val Dn)
(when (== This (: grp))
(super Val Dn) ) )
################################################################
'val>' can be omitted, because 'set>' never sets any value to the
secondary group members.
A good test to see if JS is functioning properly, is scrolling a +Chart
with JS turned on:
(<table> NIL NIL NIL
(do 5
(<row> NIL
(gui 1 '(+Radio) NIL "chart1")
(gui 2 '(+Radio) -1 "chart2")
(gui 3 '(+Radio) -2 "chart3") ) ) )
(scroll 5)
If you click a pattern, and it scrolls up and down in the chart, you
know that setting, fetching, and checking of the individual radio
buttons works.
I'd like to stay with the "field-reference" philosophy, as this
integrates optimally with all other parts of the GUI. And, more
important, it provides the simplest and most modular solution for the
typical case. In more special scenarios, like your example of
dynamically generated radio button lists, it should be fairly easy to
pre-process the data.
Cheers,
- Alex
--
UNSUBSCRIBE: mailto:[EMAIL PROTECTED]
