This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
When the component tree for the form is built, the getScoreComponent method of the backing bean is called, but it returns null. As a result, an output component is constructed and installed into the backing bean with a call to setScoreComponent.
if this is correct .. why another output component is created? I dont see the need since a backing bean is both ways - input and output.
When the component tree for the form is built, the getAnswerComponent method of the backing bean is called, but it returns null. As a result, an output component is constructed and installed into the backing bean with a call to setAnswerComponent .
If this edition is correct, shouldn't this be input component since answerComponent is of type UIInput?
Just as a rough guess, I'd suspect that the reason an output component was constructed is that an input component would be useless.
An input component is supposed to be able to set a backing bean property, but if you constructed one without any knowledge of what was going in, you'd have no place to put received input data to begin with. So it would be output-only purely because it had no other abilities.
However, direct control binding is overused by JSF programmers anyway. You should really only use it if you intend to make the backing bean dynamically modify the View tree. For most purposes, the "value=" attribute bound to a data property is quite sufficient.
Customer surveys are for companies who didn't pay proper attention to begin with.