pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Brown <gkbr...@mac.com>
Subject Re: Disabling tree nodes, table rows, and list items
Date Wed, 29 Jul 2009 15:58:49 GMT
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 <gkbrown@mac.com> 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


Mime
View raw message