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.

r51457: added 'filter' facet to ace:column in order to arbitrarily specify filtering values

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.

r51470: added added many-to-one filtering support to ace:dataTable
r51471: modified filtering demo to show this functionality

r51484: added listeners to close filter facet when clicking outside of it

Committed to the 3.3 EE maintenance branch:
r51487: added fontawesome, since it's needed for this improvement
r51488: added 'filter' facet to ace:column in order to arbitrarily specify filtering values; added added many-to-one filtering support to ace:dataTable; added listeners to close filter facet when clicking outside of it

r51849: added many-to-one filtering support for all column value types

Verified functionality ICEfaces 4 trunk, ICEfaces EE-3.3.0 maintenance branch r51533, Tomcat 8, MS Edge, IE 11, 10, 9, 8, 7, FF 47, Chrome 57.
Added test apps ICE-11298.jsf to:
http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces4/Sparkle/Nightly/dataTable
http://dev.icesoft.com/svn/repo/qa/trunk/Regression-Icefaces2/Sparkle/Nightly/dataTable

There is an issue (all browsers) only the very first time that a filter selection is checked and can be seen in the new QA test apps as well as in the showcase demo ace:dataTable > Filtering.
After making one selection from the Chassis menu the menu closes immediately and does not filter the data. After reopening the menu, it will stay open while making multiple selections. Once the menu is closed again the filtering will occur as expected.

The above is not really an issue. It's the same situation that we've seen that happens at the very first request when loading a page directly: there's no session created yet, so the first request contains the jsessionid parameter, and that causes the whole form to be updated, so the table is rendered again in it's initial state (with the facet closed). This doesn't happen when loading the main showcase page first and navigating to the demo by clicking the menu on the left or by simply using the jsp redirection technique that we use in most of our apps, including the showcase (response.sendRedirect("x.jsf")).

Tested with ICEfaces 4 trunk r51581 using myfaces 2.2.12 libs. The filter selection issue as seen in my last comment is present even when loading the main showcase page first and navigating to the demo by clicking the menu on the left.
When using mojarra libs and navigating through the menu the issue is not seen.

r51607: added code to preserve the open/closed state of the filter facet across requests, in order to avoid the facet suddenly close when the whole table markup is updated

This takes care of the issue with myfaces as well as the issue with mojarra.

Verified ICEfaces 4 trunk r51622, myfaces and mojarra libs, Tomcat 8, MS Edge, IE 11, 10, 9, 8, FF 47, Chrome 57.

r51632: backported last fix to the 3.3 EE maintenance branch

Verified ICEfaces EE-3.3.0 maintenance branch r51633, myfaces and mojarra libs, Tomcat 8, MS Edge, IE 11, 10, 9, 8, 7 FF 47, Chrome 57.