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.
Seam
JSF UISelectBoolean, UISelectMany, UISelectOne, UISelectItem and UISelectItems families
checkbox
h:selectBooleanCheckbox
The checkbox type element represents the HTML input type checkbox. Example of the representation in the source content is shown below.
<input type="checkbox"
name="jsftags:_id6" checked
title="emailUpdates" />
Would you like email updates?
The descriptors hold the dynamic specification, which is combined with specification in the source content to arrive at the implementation syntax. For the descriptors entries, see the overview section of the element descriptor, as well as the individual attributes entries.
Example of the final syntax is shown below.
<h:selectBooleanCheckbox
title="emailUpdates"
value="#{jsfexample.wantsEmailUpdates}" >
</h:selectBooleanCheckbox>
<h:outputText
value="Would you like email updates?"/>
checkboxGroup
h:selectManyCheckbox h:selectOneCheckbox
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.
Unlike most of the other elements this type of element corresponds to multiple HTML elements, and has layout implications. In the source content, annotations would enclose the mock representation. For clarity, a specification of layout is recommended, although the default horizontal line direction could be assumed.
In the mock-up process, it is wise to study the layout specification of the rendered code and duplicate such. An example is shown below.
The descriptor entries are similar to those for the select element, with the exception that the value binding could accept List of strings. Just like the select element, the nature of the binding would determine whether the resulting JSF component is One or the Many type.
The descriptors hold the dynamic specification, which is combined with specification in the source content to arrive at the implementation syntax. For the descriptors entries, see the overview section of the element descriptor, as well as the individual attributes entries.
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 recognized 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
refer 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 JSF implementation.
caption - {object.label} value ? {object.value} enable ? behavior or expression
The entries in the descriptor
would be extracted and used to populate the JSF h:selectItem tag. The caption and value bindings must return Java String
The syntax above is used when the two required binding return String objects. There is a shorter syntax that is used
with bindings returning javax.faces.model.SelectItem, this is shown below.
<f:selectItem value="#{object.cheeseItem}"/>
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
<f:selectItem itemLabel="Cheese" itemValue= "1">
options
f:selectItems
The options element would show up in the source content as a set of HTML option tags, with mock values.
This is illustrated in the section on the option type element.
In the descriptor it would show up with the following entries. It should be noted that there are other attributes, like enable and goup-id that could be
applied to the individual option within the options collection. It is easier for those specifications to be encapsulated within the model
id
This is the id of the associated select element
caption
The caption or label binding
{object.property[].label}
value
The value or key binding
{object.property[].value}
The implementation tag is the f:selectItems.
<f:selectItems value="#{forms.menuItems}"/>
The value bindings allowed for this component are 1) an instance of SelectItem, 2) array or collection of SelectItem, and 3) Map.
To achieve this, the label and value bindings must be converted and presented in the desired forms, and exposed to the view as a property of the backing beans.
This would involve creating an instance of the object as collections stored in the exposed property. This is not an uncommon step, since the domain model objects
might need transformation into transfer objects needed by the view tier.
new SelectItem(object.property[].value, object.property[].label);
hashMap.put(object.property[].value, object.property[].label);
(the binding are shown with dWebSpec for illustration only. They would need to be resolved into objects within collections)
radio
The radio
element is represented in the descriptor by two elements, the radio and the
option element. The latter provides the selection option, whereas the earlier
the selection input.
This element would be used with a repeat component to presesent a group of options. For JSF
there is no component that represents this. Although the h:selectOneRadio could be used to represent a single radio element
by assoicating with one f:selectItem or f:selectItems that return a single option. Even this would prove to be useless, since
the radio input is used to select one of mutiples.
radioGroup
h:selectOneRadio/h:selectManyRadio
dWebSpec element of type
radioGroup represents a group of input radio buttons that is bound to a collection.
This would render a group of radio buttons, with options of vertical or
horizontal arrangement. Also with option of label on the left, right, top or
bottom.
Unlike most of the other elements this type of element corresponds to multiple HTML elements, and has layout implications. In the source content, annotations would enclose the mock representation. For clarity, a specification of layout is recommended, although the default horizontal line direction could be assumed.
In the mock-up process, it is wise to study the layout specification of the rendered code and duplicate such. An example is shown below.
The descriptor entries are similar to those for the select element, with the exception that the value binding could accept List of strings. Just like the select element, the nature of the binding would determine whether the resulting JSF component is One or the Many type.
The descriptors hold the dynamic specification, which is combined with specification in the source content to arrive at the implementation syntax. For the descriptors entries, see the overview section of the element descriptor, as well as the individual attributes entries.
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 than a drop down menu type entry.
Example of representation in the
source content is shown below.
The two styles of rendering, list or menu, are determined by the size attribute.
This would be designated in the source content, and would pass through to the final component.
The descriptor entries would
capture the dynamic aspects 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.
The first set is shown below, pertains to the selected value(s).
id
value
customerId
{selectCustomerOrder.customerId}
orderId
{selectCustomerOrder.orderIds[]}
To complete the specification, the options involved must be explored.
The representation is covered under the options type, in this section.
The conversions from the combination of source content and the descriptors, to the implementation components are as follows.
size = 1 or others
binding = single or collections
Components (Caption)
1
single
h:selectOneMenu
1
collections
h:selectManyMenu
others
single
h:selectOneListbox
others
collections
h:selectManyListbox
The size, which determine the rendering, would be determined from the source content. The binding in the descriptors would either involve single value or collection.
For JSF it is specifically an Array of Objects that is needed for the multiples.
Technologies
