CODEWITHSUNDEEP
jsfconvertersviewparams
Marcus Junius Brutus
Marcus Junius Brutus

Reputation: 27286

in case of an f:viewParam bound to a converter, why do we need the Converter#getAsString

Say I have the following f:viewParam definition:

<f:metadata>
    <f:viewParam name="cust-id" value="#{CustomerCEVController.customer}" 
        converter="#{customerConverter}" converterMessage="Unknown customer, please use a link from within the system."
        required="true" requiredMessage="cust-id f:viewParam not present"
    />
</f:metadata>

I navigate to the intended page with a "?cust-id=2342" parameter in the URL and so the role of the getAsObject method in the converter is to obviously instantiate the Customer field in the backing bean (e.g. by doing a DB query based on the cust-id value). What's not very clear to me is why we need the getAsString method and how it is employed. This is not a question about the role of the getAsString in converters in the usual case, i.e. in the binding between the .xhtml view UI elements and the backing bean where their role is straightforward. I 've also read here that we can treat the f:viewParam as a UI input element for GET parameters but the role of the converter in the opposite direction doesn't make sense to me.

Upvotes: 0

Views: 278

Answers (1)

BalusC
BalusC

Reputation: 1108802

The getAsString() is indeed not used in case of <f:viewParam>, but an existing converter can be reused for other components where getAsString() is really been used.

E.g.

<h:outputText value="#{CustomerCEVController.customer}" converter="#{customerConverter}" />

or

<h:selectOneMenu value="#{CustomerCEVController.customer}" converter="#{customerConverter}">
    <f:selectItems value="#{data.customers}" />
</h:selectOneMenu>

It's up to you whether to implement getAsString() as per its contract or not. If you don't, then your converter would not be reuseable for other components at all.

Upvotes: 1

Related Questions