It's caused because the UIInput#getValue()
defaults to Object
, not String
. As long as you don't explicitly bind the value
attribute of an UIInput
based component to a backing bean property of a more specific type, like String
, no specific converter will be looked up either.
It should work if you change
<p:inputText onkeyup="PF('dataTableUIWidget').filter();"/>
to e.g.
<p:inputText value="#{bean.filter}" onkeyup="PF('dataTableUIWidget').filter();"/>
with a private String filter
property (and a getter+setter). But this is indeed clutter if you don't use this property anywhere else in the model.
The alternative is indeed explicitly declaring a converter via the converter
attribute. According to @FacesConverter
contract, it's not possible to simultaneously declare both a converter ID and a converter for-class on the same converter class like so
@FacesConverter(value="stringTrimmer", forClass=String.class)
public final class StringTrimmer implements Converter {
// ...
}
Only the converter ID would be registered and a warning will be printed to the server log.
WARNING: @FacesConverter is using both value and forClass, only value will be applied.
But, it is possible to have both @ManagedBean
and @FacesConverter
on the same class. You should only understand that they don't cooperate with each other and that completely independent instances would be created. But this shouldn't harm if the converter is designed to be stateless (i.e. all state is kept within the method block and the class doesn't have any instance variables/dependencies).
@ManagedBean
@ApplicationScoped
@FacesConverter(forClass=String.class)
public final class StringTrimmer implements Converter {
// ...
}
This way you can keep having the benefit of forClass
and still be able to reference the converter as a managed bean via #{stringTrimmer}
on those components where forClass
can't apply.
<p:inputText onkeyup="PF('dataTableUIWidget').filter();" converter="#{stringTrimmer}" />