The selection input elements
provide means of choosing amongst predetermined list of items.
However, there are some special
issues involving selection elements. The first of which has to do with the
fact they involve multiple bindings, one for the selected items, and one or
more for the options to be selected from.
The dWebSpec types involved in
selections are radioGroup, checkboxGroup, select and radio type elements.
These are shown in the table below.
Type
value
options
comment
checkbox
single
X
True/false entry
radio
single
single
Group member have same ID
radioGroup
single
collection
checkboxGroup
single/ collection
collection
select
single/ collection
collection
The first one, checkbox, is not
a selections element, it as input elements that allows for true/false
entries; it is included here because of the relationship with the
checkboxGroup.
The radio input allow selection
of one of multiple options, as such, standalone it is of no use. When included
multiple times within a form, with each instance bound to different singular
value, but all instances sharing an identifier, they in essence form a radio
group.
The radioGroup would be bound to
a collection of options, with which it would render the member radio buttons
with a singular value identifier. In short the difference between the radio
and radioGroup, is that the earlier allows fine grain binding of values to
individual radio elements, whereas the values for radioGroup would come from
a collection.
The checkboxGroup is similar to
the radioGroup, in that it would be bound to a collection of options, with
which it would render the member checkboxes with a single identifier.
However, it could allow single or multiple selections; the latter would imply
that selected values would be returned as collection. The select element has
identical binding structure with the checkboxGroup.
Struts 1.x
checkbox
html:checkbox
The
representation of checkbox in the source content is as shown below
<input type="checkbox">
The standard input attributes
are relevant to this element:
However, the conversion type
must be boolean, for Struts, as reflected in the form bean. For the
auto-population to work correctly, the bound value must be reset to false
within the reset() method of the form bean.
checkboxGroup
html:multibox/
logic:iterate
dWebSpec element of type
checkboxGroup represent a group of checkboxes that is bound to a collection.
This would render a group of checkboxes, with options of vertical or
horizontal arrangement. Also with option of label on the left, right, top or
bottom.
The implementation of this
element on the Struts platform involves multiple tags.
It is the multibox tag that is
at the center of checkboxGroup implementation. However, there is need for
behavior-repeat implementation to complete the scheme. This behavior is covered
in its own section as such we shall not repeat information relating to it.
What is worth mentioning here is that this behavior would take a collection,
and present a member object for each iteration of the behavior. This is used
to instantiate an option at a time.
The transformation into
implementation code is as shown below.
option
html:option
The element of type option is
used to render the HTML <option> tag. It would be represented in the
source content in this form, as shown below. This is the singular option, for
which a complimentary plural options element is provided.
In using the source content as mock-up,
it is recognize that some of the options included would be for mock
presentation, whereas others could provide the final value. As a default, all
options specified are construed as final values. This would allow
specification of no selection option that is common in specifications, or
else static options like Male or Female.
The mock-options that are not
meant to be retained should be wrapped in annotations. As shown below, these
options are wrapped with the options annotation, which indicate that they
would be rendered with that element. Any section of the page that is not
meant for implementation could be wrapped with the segment annotation, with
the visible attribute set to false. For more discussion on this, please
refere to the segment descriptor.
The id of the option is the same
as the id of the enclosing select element.
The value is the binding
{object.property} that provides the value, or else, a literal string. Whereas
the caption is the binding {object.property} that provides the label, or a
literal string. The latter could also be a key to an externalized string.
Despite using the same convention, object binding and externalized strings
are usually distinguishable when necessary, form the object definition,
resource definition, etc.
The following are attributes of
the dWebSpec option element that are relevant to Struts implementation.
caption - {object.label}
value ? {object.value}
enable ? behavior or expression
The entries in the descriptor
would be extracted and used to populate the Struts html:option tag.
Although the entries in the
descriptor are shown as value bindings, they could also be literal string, in place
or externalized. Examples are shown below.
caption (literal) the body of
the tag
<html:option value="test">Test</html:option>
caption (externalized) ? key
<html:option key= "page.test" value="test"/>
options could be disabled: enable ? converse of disable
This are obtained from the
descriptors as follows:
caption, ?-
{object.property[].label}
value, -
{object.property[].value}
The binding to the options is a
collection, from which an individual member would supply the label and value.
This binding is shown above descriptively. The translation to the
implementation tag is shown below.
NOTE:
Although html:options and html:optionsCollection are equivalent to the dWebSpec
options element, the reverse is not true. The dWebSpec options element also
represent the data structure for the radioGroup and checkboxGroup elements.
NOTE:
Struts Options Variety
There
are indeed the html:options and html:optionsCollection tags to choose from.
The duplicity should be viewed from historical perspective. The Options tag
was the earliest, and has evolved over the years to accommodate many ways
that the collection could be specified. In providing this accommodation,
there are many ways that groups of its attributes could be interpreted. Such
varieties involve the fact that collection could be provided through scoped
attributes, or indirectly though the attributes of scripting object.
Furthermore, label and values sources could be different or same. The
html:optionsCollection tag has more streamlined set of attributes and should
be more convenient for usage with collections derived from the attribute of
an object, like the form bean.
NOTE:
Label value bean
Struts
provides a class that could be used for the objects in the options
collections. That is the LabelValue class [
org.apache.struts.util.LabelValueBean
This class has the label and value attribute, which
are the default for the Struts option collection tags. If this is used as the
data source, there is not need to specify the label or value attributes, in
the options tags.
radio
html:radio
The radio
element is represented in the descriptor by two elements, the radio and the
option elements. The latter provide the selection option, whereas the earlier
the selection input.
For the option,
the following attributes that provide the label and value are important.
caption - {object.label}
value ? {object.value}
For the radio input, it is the
value of the descriptor that is important, in providing the binding
{object.property}.
The radio binding would be
represented in the name and property attributes of the html:radio tag. The
option value would be reflected in the idName and value attribute. An output
element (bean:write) would then be position next to the radio that reflect
the option caption.
The same radio binding could be
repeated with different options. It is the selected and submitted option
would be assigned to the radio binding.
radioGroup
html:radio/logic:iterate
The radio group
represents an element that could render a group of option tag. The group
would behave like a single input element, but associated with a set of
options.
As such, a
radioGroup is represented by an input element, and options elements, or a set
of option elements.
The physical
representation in the source content is a set of radio elements that have the
same identifier, but associated with different value options.
This could be implemented with
individual radio elements with individual binding. Or else, as a radioGroup
with single binding, which would be a collection.
To represent this in the
descriptor, there would be a radioGroup element with it binding, then the
options element, with its collection binding.
The radioGroup element does not
translate into a single tag on the Struts platform. Just like the
checkboxGroup, the implementation would involve the repeat behavior. The
implementation is just slightly different from that of the radio element. The
repeat behavior would be applied to render the radio elements as many times
as there are option. The repeat behavior would then provide the option for
each instance of the rendering, for the inclusion of the label and value.
The implementation on the Struts
platform, would appear as follows:
First, as could be seen from the
implementation, the input tag involve does not show the binding for the
collection of options, but binding to a singly option provided multiple
times, by the surrounding repeat behavior. The property is obtained from the
enclosing form object. It is the "category" object that is introduced
iteratively and used for the label and value pairs.
select
html:select
This is used to render the HTML
<select> input tag. It works with the option or options element, to
provide the item(s) to be selected.
There are variations to the
select mode that could be included in their representation in the source
content. The present of the multiple would allow multiple selections. Whereas
the size entry of greater than one would render a list box of the size designated,
rather tan a drop down menu type entry.
Example of representation in the
source content is shown below.
NOTE:
Mixture of Static and Dynamic Specifications
It is
possible to specify HTML <option> in the content source that is not
included in the descriptors. They would simple be considered to be static:
without dynamic data bindings. It is noteworthy that options that are not
enclosed with the mock-up data segment notations are part of the final
specifications. For instance, an option could be labeled, "Please make a
selection" or blank option, and given a null string value, this would be
included. The options could also be static, like North, South, Ease and West.
These could stay in the content source, without being reflected in the
descriptors. Any option within the annotation is assume to be part of mock
data.
The relevant attributes for the
select element from the descriptor are the full set of attributes as they
pertain to input elements.
These additional attributes are
recognized as pass through from the source content, for the select element: multiple and size
The descriptor entries would
appear as follows.
There are two set of entries,
one set for the selected values, the other for the options available. We
shall explain along this line.
id
value: object
name
property
customerId
selectCustomerOrderForm
customerId
orderId
selectCustomerOrderForm
orderId
Each of these select elements is
bound to a single property as shown in the table above.
The bindings of the options
however, involve collections.
id
Collections
Label (Caption)
Value
customerId
!.customers
.customers[].companyName
!.customers[].customerId
orderId
!.orders
.orders[].orderId
!.orders[].orderId
The implementation of the two
selection elements is shown below.
Technologies
