One problem with the object-oriented ideas behind WOM arises
with radio buttons. In HTML, one displays a radio button by using the
INPUT
element with type RADIO
:
<INPUT TYPE=RADIO NAME=my_button_group>There can be any number of elements with the same value for the
NAME
attribute, forming a button group with that name.
Each element can be placed anywhere in a page, but all elements in
a group interact, in the sense that if the user presses one button,
all the others pop out.
The question arises of how, using WOM, to place radio buttons. The
immediately obvious way would seem to be to
make each button a separate object.
However, if we compare buttons and menus, we can see this to be the
wrong choice. A group of buttons is like a menu. If the user presses
one, we want to know which this was: its identity should
be available from the
group's value
attribute, in the same way that a menu's value
is the
option selected on it. So the entire group should be treated as
one object.
However, it is a strange kind of object because it is distributed
through space. We can think of a group of buttons as like a cluster of
switches connected by wires: the switches poke through holes in
the page and are visible from the front, while
the wires remain behind, hidden.
But if the entire group is a single object, how can we place
individual buttons? To answer this, I introduced the
Slice
element.
This has two positional arguments, the first being an instance path, and
the second being a string. The button group would be created as a
detached instance, and individual buttons would be placed as slices:
<Instance><RadioButtons rb></Instance> ... Zoom in: <Slice rb "zoom_in"> Zoom out: <Slice rb "zoom_out"> Reset: <Slice rb "reset"> ... <OnSubmit rexx> { ... selected_value = $rb~getValue ... } </OnSubmit>In this code,
$rb~getValue
would return "zoom_in"
,
"zoom_out"
or "reset"
.