OK, I created the issue. If anyone has any additional comments, please
attach them there. Thanks.
On Jul 29, 2009, at 12:15 PM, Greg Brown wrote:
Any other comments on this? I just checked in the generic Filter
interface, and I'm planning to open a JIRA ticket to modify the
disabled item APIs and another one to create FilteredList. Any
concerns before I do so?
On Jul 29, 2009, at 11:58 AM, Greg Brown wrote:
Great point. We currently clear the disabled indexes when the model
data is sorted. With a disabled item filter, we wouldn't need to do
that.
On Jul 29, 2009, at 11:53 AM, Noel Grandin wrote:
Great idea. Indexes are very hard to work with once you have widgets
that support sorting.
On 07/29/2009, Greg Brown <[email protected]> wrote:
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
--
Sent from my mobile device
