Recommended phase for "check all" button

Question

Hello,
I have a question about the recommended processing phase for an event listener that implements a "check all" button which fills a number of checkboxes on the page. Should this be in Apply Request Values, or later? And does my handler have to update only the checkbox model values, or also the checkbox UI components?
The best analogy in the cardemo example is to CarActionListener, which handles events for setting checkboxes and dropdowns in accordance with some standard car accessory packages like "luxury," "performance," etc. This event listener executes during Apply Request Values. But I doubt this is the recommended implementation, since it seems quite inefficient in other ways.
Specifically, I notice that the handling methods -- like processLuxury(), processPerformance(), etc. -- take it on themselves to modify not only all the model values for every car accessory, but also all the other UI components. Is this right? If the JSF framework is smart enough to maintain a binding between the model values and the UI components, can't I use that mechanism when I want one UI component to modify the state of other ones?
Thanks,
Alexis

Answer 1

Hello,
I have a question about the recommended processing
phase for an event listener that implements a "check
all" button which fills a number of checkboxes on the
page. Should this be in Apply Request Values, or
later? And does my handler have to update only the
checkbox model values, or also the checkbox UI
components?I would recommend having this listener run in Apply Request Values phase. Further, you want to make sure that your listener calls FacesContext.renderResponse() to cause the rest of the phases be skipped, so that the current page will be redisplayed.
The best analogy in the cardemo example is to
CarActionListener, which handles events for setting
checkboxes and dropdowns in accordance with some
standard car accessory packages like "luxury,"
"performance," etc. This event listener executes
during Apply Request Values. But I doubt this is the
recommended implementation, since it seems quite
inefficient in other ways.
Specifically, I notice that the handling methods --
like processLuxury(), processPerformance(), etc. --
take it on themselves to modify not only all the model
values for every car accessory, but also all the other
UI components. Is this right? If the JSF framework is
smart enough to maintain a binding between the model
values and the UI components, can't I use that
mechanism when I want one UI component to modify the
state of other ones?
The original code for Cardemo was written very early in the life of JavaServer Faces, and doesn't take advantage of all the newest features. This is one of the things we're reviewing before the next release, so that CarDemo illustrates the most recent recommended practices.
Thanks,
AlexisCraig