#Obtain value oneradio jsf full#
#Obtain value oneradio jsf code#

#Obtain value oneradio jsf code#

Now the component is developed as working prototype, the size of the required code base is breathtakingly small. When I started out, it seemed a real challenge. The article goes into a few relatively interesting aspects of custom JSF development, including the use of facets, accessing child components during rendering, manipulating children and transfering both child-elements and attributes etc. Of course we would have the same effect if the set of colors had dynamically changed from a small one to a large one. With the same set of five colors to choose from, when we change this value from 6 to 4, we essentially tell the application that our set of colors is now a large set, and therefore should be displayed as dropdown list: With the first radio group (labeled Set the number of selections where small becomes large) we can specify when we switch from a small set of selection options to a large set. Our SelectSwitcher contains three facets: one for a small set of options (verticallay laid out radio buttons), one for a large set (dropdown list) and one for the read only situation (where no options need to be presented at all). Illustrated in a simple screen shot: we have a selection element five colors to choose from. So depending on first of all the number of options available to the user and second of all the boundary between a small and large number of options, the page will display either the one or the other selection component. Depending on the number of select-options – determined dynamically at run time – one of the facets is rendered. The SelectSwitcher is a component that wraps multiple select-components in its facets.

Well, this is exactly where the custom component presented in this article comes in. So: do we throw the common wisdom out of the window? So any choice made during development for either radio buttons or drop downlist may be invalid at run time. If these values are retrieved from a dynamic collection, perhaps fueled by a web service or database query, the size of the set of value can vary wildly. And that is: we may not know beforehand, at design time, what the number of allowable values is going to be. There is a challenge however with this common wisdom, apart from the question where exactly lies the boundary between a small and larger number of allowable values. For a really large number of options, another component usually comes into play: the List of Values, either in a floating DIV, a popup window or an AJAX powered suggestion element.

The values to choose from are still very much accessible to the end user.

#Obtain value oneradio jsf full#

With an increasing number of options, a drop downlist or list-box may be better, as they occupy less real estate than the full set of radio buttons would. Depending on several considerations, such as the look and feel requirements of the interaction designers and end users and the number of options to be presented in the selection component, a specific component is used in a page.Ĭommon wisdom has it that for a small number of allowable values, radio buttons – laid out horizontally or vertically – are a good choice. These selection components can have various shapes, such as list box, dropdownlist and radio buttons. Most applications also have selection components through which the user can select one of a set of allowable values. Let me give you a little background: most applications present the end user with text fields where the user can type in new values. This article shows a new component that may actually make sense in real applications. In keeping with a short tradition, today is another day during my Christmas break on which I had some time to dabble in Java Server Faces and particularly the creation of custom JSF components.