PropertySelection and IPropertySelectionModel in Apache Tapestry (
Page 1 of 5 )
We already encountered PropertySelection in one of the previous articles so we know that it is a Tapestry component used to display a drop-down list, allowing the user to choose one of multiple options. You might think that the way in which options are provided to this component (through its model binding) is somewhat cumbersome when all you need to do is select one of a few strings. However, PropertySelection was designed with a great deal of power and flexibility in mind, and I hope that today you will appreciate this.
A
downloadable zip file is available for this article.
Let's add one more piece of functionality to the CelebrityCollector application. Say we want to select a "celebrity of the week." This will cause one of the celebrities in our collection to have his or her name displayed on the home page of the application.
One of the ways we can do this is by having a drop-down list with celebrities' names somewhere in the application, and a button that will assign a selected celebrity to be the "celebrity of the week," something like this:
And here is a mock up for this piece of the user interface:
<h4>Select a Celebrity of the Week:</h4>
<form action="">
<select>
<option value="1">Angelina Jolie</option>
<option value="2">Bill Gates</option>
</select>
<input type="submit" value="Save"/>
</form>
I suggest placing this bit at the CelebritiesList page, just under the table. At a later stage we might add a special Admin page and move it there.
Let me briefly remind you how the HTML <select> element works. It has a number of <option> child elements that provide the options available in the drop-down list. The text inside an option, such as "Bill Gates" serves as a label for that option; this is exactly what the user sees.
The value attribute is optional. If it is not provided, the label will be used as the value for that option.
When the form containing the <select> is submitted, it is the value of the selected option which gets reported to the server. For instance, in the example above, if the user selected Angelina Jolie, what gets submitted to the server is the value "1."
On the server side we'll have a property of the page class, and we're going to store the celebrity, selected by the user, into that property. So on one hand we have the value "1" arriving from the user, and on the other hand we have a page property of the Celebrity type in which we are going to put the result of the selection. You can see a significant gap which we'll need to fill in with some code converting the "1" into a Celebrity object filled with information on Angelina Jolie.
There is also another task at hand. We have a List filled with Celebrity objects on the server side, but on the client side we want to have a <select> with values and labels of its options properly filled in. That's another piece of code to write. And every time we'll want the user to select a Celebrity, we'll have to write some code to enable this functionality, more or less the same code again and again. Wouldn't it be great to delegate this work to a component?
