By the way, the Filter interface would also have applications
elsewhere, such as in a org.apache.pivot.collections.FilteredList
class. This class would implement the List interface and would
internally maintain a filtered copy of the source data, allowing it to
be used as the model of a table view and independently sorted, etc.
On Jul 29, 2009, at 10:47 AM, Greg Brown wrote:
All,
Currently, Pivot allows a caller to disable individual items in
list, table, and tree views via index (or path, in the tree case).
This works, but does require some effort on the part of the caller,
since the caller needs to know which indexes map to the items they
want disabled.
I'd like to propose what I think is a better solution: what if we
instead allow the caller to set a "disabled item filter"? This would
basically amount to an implementation of some interface such as:
package org.apache.pivot.util;
public interface Filter {
public boolean accept(Object object);
}
or possibly:
package org.apache.pivot.util;
public interface Filter<T> {
public boolean accept(T t);
}
It would certainly simplify the code in TreeView, TableView, and
ListView, since we'd no longer need to maintain the list of disabled
indexes. It is also more efficient, for the same reason. Finally, it
is more flexible, since any items matching the filter would be
automatically disabled - the caller would not need to manually
update the disabled index list as new items were added.
The downside is that, if the caller does actually want to disable
items by index, it would be difficult (or impossible) do. We could
add an index or path to the accept() method, but that seems like
overkill. I guess the question is - what use case are we addressing
with disabled items? Is a caller more likely to want to disable
items by nature or by index? I'd guess the former, but I'm not 100%
sure.
Please let me know what you think.
Thanks,
Greg
