Example 1:
Let's suppose the following code:
<h:form>
<h:selectManyListbox value="#{playerBean.selectedRanks}" converter="javax.faces.Integer">
<f:selectItems value="#{playerBean.playersRanks}"/>
</h:selectManyListbox>
<h:commandButton value="Select" action="#{playerBean.selectedAction()}"/>
</h:form>
Let's start by supposing that the above built-in converter is not specified. Basically, the playersRanks is a list of integers that "populates" our list, and the selectedRanks represents the user selections:
private ArrayList<Integer> selectedRanks;
private static final ArrayList<Integer> playersRanks;
static {
playersRanks = new ArrayList<>();
playersRanks.add(1);
playersRanks.add(2);
playersRanks.add(3);
}
public ArrayList<Integer> getPlayersRanks() {
return playersRanks;
}
public ArrayList<Integer> getSelectedRanks() {
return selectedRanks;
}
public void setSelectedRanks(ArrayList<Integer> selectedRanks) {
this.selectedRanks = selectedRanks;
}
So, the user may select the ranks and submit them without issues/errors. Even if no error occurred, we can notice a "strange" behavior if we try to run the following snippet of code:
<ui:repeat value="#{playerBean.selectedRanks}" var="i">
#{i}: #{i.getClass()}
</ui:repeat>
The output reveals that the selected ranks are strings, not integers as we expected to see:
1: class java.lang.String
3: class java.lang.String
The explanation relies on the fact that "the generic type information of List<Integer> is lost during runtime and therefore JSF/EL who sees only List is not able to identify that the generic type is Integer and assumes it to be default String (as that's the default type of the underlying HttpServletRequest#getParameter()call during apply request values phase) - BalusC".
There are two approaches:
· explicitly specify a Converter
· use Integer[] instead
In this case, we can use the built-in javax.faces.Integer built-in converter. Now, we can perform the same test and the output will be:
1: class java.lang.Integer
3: class java.lang.Integer
Example 2:
This use case continue the story from the above use case. Cosider this code:
<h:form>
<h:selectManyListbox value="#{playerBean.selectedPlayersList}" converter="playerConverter">
<f:selectItems value="#{playerBean.playersList}" var="t" itemLabel="#{t.label}" itemValue="#{t}"/>
</h:selectManyListbox>
<h:commandButton value="Select" action="#{playerBean.selectedAction()}"/>
</h:form>
Basically, this time we use data for which we don't have a built-in converter available. The custom converter used here is needed because this time the list is "populated" with several Player instances:
private ArrayList<Player> selectedPlayersList;
private static final ArrayList<Player> playersList;
static {
playersList = new ArrayList<>();
playersList.add(new Player("Rafa", "Rafael Nadal"));
playersList.add(new Player("Roger F", "Roger Federer"));
playersList.add(new Player("Nole", "Novak Djokovic"));
}
public ArrayList<Player> getPlayersList() {
return playersList;
}
public ArrayList<Player> getSelectedPlayersList() {
return selectedPlayersList;
}
public void setSelectedPlayersList(ArrayList<Player> selectedPlayersList) {
this.selectedPlayersList = selectedPlayersList;
}
// Player class snippet of code
public class Player implements Serializable {
private String label;
private String value;
public Player(String label, String value) {
this.label = label;
this.value = value;
}
...
Remember from the above use case that the generic type of List<> is lost during runtime. Since the selected items are treated as strings instead of Player instances, the below code will cause an error because #{i.label} cannot be evaluated:
<ui:repeat value="#{playerBean.selectedPlayersList}" var="i">
#{i.label}: #{i.getClass()}
</ui:repeat>
Since there is no built-in converter for converting strings to Player instances, we need a custom converter as below:
@FacesConverter("playerConverter")
public class PlayerConverter implements Converter {
@Override
public Object getAsObject(FacesContext context, UIComponent component,String value) {
String[] parts = value.split("/");
return new Player(parts[0],parts[1]);
}
@Override
public String getAsString(FacesContext context, UIComponent component,Object value) {
return value.toString();
}
}
Now, everything works as expected!
JSF 2.3
Well, while example 1 is pretty simple to "fix", the second example is not so easy since it requires us to write a custom converter. But, JSF 2.3 comes with a new feature that is capable to detect Converter based on 1st UISelectMany item and save us for using a built-in converter or writing a custom one for this purpose. So, in JSF 2.3 the below two codes will work as expected:
1: there is no need to specify a built-in conveter
<h:form>
<h:selectManyListbox value="#{playerBean.selectedRanks}" converter="javax.faces.Integer">
<f:selectItems value="#{playerBean.playersRanks}"/>
</h:selectManyListbox>
<h:commandButton value="Select" action="#{playerBean.selectedAction()}"/>
</h:form>
<ui:repeat value="#{playerBean.selectedRanks}" var="i">
#{i}: #{i.getClass()}
</ui:repeat>
2: there is no need to write/specify a custom converter
<h:form>
<h:selectManyListbox value="#{playerBean.selectedPlayersList}" converter="playerConverter">
<f:selectItems value="#{playerBean.playersList}" var="t" itemLabel="#{t.label}" itemValue="#{t}"/>
</h:selectManyListbox>
<h:commandButton value="Select" action="#{playerBean.selectedAction()}"/>
</h:form>
<ui:repeat value="#{playerBean.selectedPlayersList}" var="i">
#{i.label}: #{i.getClass()}
</ui:repeat>
For studying the implementation please download Mojarra source code and check out the javax.faces.component.UISelectMany, com.sun.faces.renderkit.html_basic.MenuRenderer (especially, MenuRenderer#getConverterForSelectManyValues()method) and com.sun.faces.util.getConverterForClass().
Niciun comentariu :
Trimiteți un comentariu