356
Chapter 10
In addition to the child components, the UIDateRangeChooser component has an attribute that specifies the maximum number of days in the date range. The correctness check for the days in the range should be implemented in the component itself instead of as an external Validator, since the definition of validity is in the component itself. Of course, the validation could be implemented as a custom Validator that has its own configuration, but the probability of being able to reuse the validation functionality is slim, and the cost of having an additional class to maintain is higher than the gain. No matter what kind of custom component you are building, it will have responsibility in this phase. The component with new behavior will have to manage the validation of the data related to the new behavior. Aggregating components will have to manage the validation of the aggregated data and finally components that manage additional HTML elements will have to validate any input the user made on the controls.
Update Model Values This phase involves moving the validated data from the component to the model objects. Again the processing happens depth first. Each UIInput component in the tree is told to update its model with the updateModel method. Your custom component will then be responsible for applying its current value to the underlying model object. Remember not push the value down to the model object if any part of conversion or validation failed. The particular attribute to be updated is referred to by the value attribute. In most cases, the default implementation of this method inherited from UIComponentBase will suffice, so you will not have to do anything specific for your components. The one caveat is the aggregated component. Often the aggregated component has several different values that need to be applied to the underlying model. You have several options in the way you apply these updates. You can combine your aggregated data into a single JavaBean that is created during the conversion process in the Apply Request Values phase. This approach has the advantage of being most like the rest of the JSF components (that is, a component typically has one value attribute). Alternately, you could provide more than one value for your aggregated component. For example, the date range chooser component we discussed earlier could have been implemented with a single value reference whose type was a JavaBean representing a date range, or the component could have had six value expressions representing the six choices the user had to make (they would of course have to have different names). Both approaches are valid, but you should consider the simplicity of the interface and the implementation before you build your component. If you choose to have multiple value expressions for your component, you will