The filter facet has been implemented and it allows app developers more flexibility in specifying filter values, but there are still internal changes that need to be made in order to fully support the scenarios with which we have been presented. It will depend on what we want to support and how much code we want to modify.
The two scenarios we are given are (1) the FirstName-LastName scenario and (2) the Multiple Checkboxes scenario to display multiple types.
Each of those scenarios requires different changes in our code in order to be supported. They aren't the same use case, structurally. We identify that three use cases for which we can add support: one-to-many, many-to-one, and many-to-many.
Scenario (1) is a one-to-many use case, and scenario (2) is a many-to-one use case, for the reasons that will be explained below. We weren't given a many-to-many scenario, but they could possibly arise as well. So far we only support one-to-one use cases.
First, we have to understand two key attributes of ace:column involved in filtering: 'filterBy' and 'filterValue'.
The 'filterBy' attribute has typically been used to specify a single EL expression corresponding to a property in the data object. When processing filters, this attribute is evaluated and the resulting string is compared against the value that was entered by the user. This attribute can actually contain multiple EL expressions, spaces and other characters. In the end it's a string that is formed by evaluating each row's data object.
The 'filterValue' attribute is the string that will be compared against each string formed by filterBy. This string is typically what the user entered in the textbos or drop-down menu, but it can also be set programmatically, as it should be in the case of using the new filter facet.
Thus, scenario (1) involves having a single 'filterValue' compared against 2 different 'filterBy' expressions (one for first name and one for last name). Scenario (2) involves having multple filter values (all the different types selected with the checkboxes) compared against a single 'filterBy' expression (the type, in this case).
Scenario (1) is actually supported now, as long as 'filterMatchMode="contains"' is used, but it wouldn't work if it's set to 'startsWith' or other mode.
Supporting many-to-one cases is less complicated than supporting one-to-many cases. For 'many-to-one' cases we only need to modify the PropertyConstraintPredicate class to loop through all the filter values. Supporting one-to-many cases involves several structural changes in data table classes.
From the user perspective, we have to decide how to specify multiple values. One possible way to specify multiple filter values would be to separate them by commas in 'filterBy', but we would have to add another boolean attribute to indicate that this attribute should be interpreted as having multiple values. Another option would be to have a new 'filterValues' attribute to specify a List or an Array of Strings. It would be more complex that simply using the existing attribute. As for multiple 'filterBy' expressions something similar applies.
This improvement seems feasible. I assume that the intention is to filter by one or the other property (e.g. if this string is found in this property or in this other property or... then include this row in the filtered set). The only constraint these properties will have to be of the same type, as specified by the 'type' attribute of the ace:column component.
The improvement will entail modifying all the FilterConstraint implementations in the org.icefaces.ace.model.filter package to support multiple values, as well as modifying the logic in processing filters to detect the case of having multiple filter values, especially in the PropertyConstraintPredicate class.