Question

I have defined an f:metadata section on my xhtml page as shown below with a f:viewParam as shown in the below excrept:

<html xmlns="http://www.w3.org/1999/xhtml" (...)>

<f:metadata>
    <f:viewParam name="cust-id" value="#{CustomerCEVController.customer}" 
        converter="#{customerConverter}" converterMessage="blah blah."
        required="false"
    />
</f:metadata>


    <ui:composition template="/templates/commonLayout.xhtml">
        <ui:define name="title">
        (...)
        <ui:define name="body">
        (...)

.. and have declared a CustomerConverter class for the cust-id parameter. The converter class getAsObject method for the property cust-id and the getter method for the backing bean customer field are all called in the PROCESS VALIDATIONS JSF lifecycle phase called BEFORE the setter method for the customer field which is called in the UPDATE MODEL VALUES life-cycle phase. As a result, at the time where the getter is called, the field is not properly initialized by the converter. So the sequence is like this (where CustomerCEVController is the backing bean class):

[ PROCESS VALIDATIONS phase START ]
[ CustomerConverter#getAsObject called ]
[ CustomerCEVController#getCustomer called ]
[ PROCESS VALIDATIONS phase END ]
[ UPDATE MODEL VALUES START ]
[ CustomerCEVController#setCustomer called ]

I am reporting the sequence based on the interspersion of logging output and a lifecycle listener I've registered. Am I missing something and if not, how can I ensure that the customer field is properly set by the converter before it is ever accessed ?

Was it helpful?

Solution

The sequence is absolutely fine. I don't understand why exactly this forms a problem for you. Perhaps you're doing some business job in the getter or setter while it doesn't belong in those methods at all? You'd need a <f:event type="preRenderView"> instead to perform that business job.

The getter is been called during the end of validations phase because at that moment the decision will be made whether to publish a ValueChangeEvent or not. For that the initial ("old") value is needed which will then be compared to the submitted/converted/validated ("new") value. When those values are inequal, then both will be passed as "old" and "new" value of the published ValueChangeEvent.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top