: Ignore wrong parameters silently

Question

We just started to migrate an older jsf 1 project to jsf version 2.3 with new requirements. Currently I am working on pages that use viewparams. what would be the right way to silently ignore wrong parameter-types?

for example with this definition for page searchResults.xhtml:

<f:metadata>
   <f:viewParam name="lastPrice" 
             value="#{ReportAgentBean.lastPrice}" converter="javax.faces.Double"/>

   <f:viewParam name="currentPrice" 
             value="#{ReportAgentBean.currentPrice}" converter="javax.faces.Double"/>

   <f:viewParam name="listPrice" 
             value="#{ReportAgentBean.listPrice}" converter="javax.faces.Double"/>
</f:metadata>

what would be the best approach to ignore invalid parameters or just handle them as null if someone fires a request like:

http://www.ourapp.com/reports/searchResults?lastPrice=undefined?currentPrice=INVALIDSTRING

which ideally would result in:

http://www.ourapp.com/reports/searchResults

thanks for any hint.

There might be a better way, but why not just pass them as string and check in a setter method if it is the real correct type? — Kukeltje, Jun 07 '17 at 18:40
we have huge forms with many inputs. and we have the requirement, that users can send links containing their specific url-parameters via e-mail. in the past i battled around with request-parameters. so isn't the new rescue for that? that way i don't need to recreate the bean-properties from the request-parameters. — doratono, Jun 07 '17 at 19:21
I never said to recreate them from request parameters. I just said to pass them as string (not using a converter) and in the setter that you call, convert to a certain type if valid and pass the value on to the real field. And in other cases set null or whatever. — Kukeltje, Jun 07 '17 at 19:31
Or maybe you can create your own converter for each type that also does what I stated above, but in the converter, so `lastPrice=undefined` does not throw an error and leaves the real lastPrice field as 'null' or 0 or... But there still might be a better solution, I'm just sharing my thoughts with the knowledge I do have (and there is a lot missing ;-)) — Kukeltje, Jun 07 '17 at 19:32
Reading https://stackoverflow.com/questions/10061422/parameter-with-fviewparam-and-facesconverter-from-cdi I'd go for the custom converters... — Kukeltje, Jun 07 '17 at 19:38
ok i got you. but would the string-parameter-approach be nice and clean? - your're right: using a custom converter instead of "javax.faces.Double" could handle that. but then i wonder, if this can be a performance issue if i have 15 or more . well i tend to like them, so i don't want to discard them. not for now... anyway, i am curious about other suggestions ;) — doratono, Jun 07 '17 at 19:43
If it is a performance issue it would be an issue to with the default converters. And I doubt it is a performance issue, since OmniFaces does something similar in their `@Param` annotation and does set the fields to null if conversion fails. And Btw, did you try what happens with invalid values? Might still be that they just set the fields to 'null'. — Kukeltje, Jun 07 '17 at 19:56

Kukeltje · Accepted Answer · 2019-02-21T00:50:20.617

As far as I know, the default faces converters you use cannot accept/ignore invalid values passed to it and ignore them.

For this to work, you need to create your own custom converters, do the casting to the right type in there and if the casting is successful, return the cast value and if it fails, return some default.

This is what you'd normally do for more complex param/converter combinations where just the presence of an id would read a full complex object from somewhere

This whole concept is also used in the OmniFaces @Param annotation which might be an interesting solution to. They set the fields to null if conversion fails. See the demo on that page too.

: Ignore wrong parameters silently

1 Answers1

Linked