You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by Greg Brown <gk...@mac.com> on 2009/07/29 16:47:49 UTC
Disabling tree nodes, table rows, and list items
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
Re: Disabling tree nodes, table rows, and list items
Posted by Sandro Martini <sa...@gmail.com>.
Ok, thanks.
Bye
Re: Disabling tree nodes, table rows, and list items
Posted by Greg Brown <gk...@mac.com>.
> - will it be possible to apply also this (or more in general a filter)
> filter to data added later, like a table containing rows, and then i
> add other rows, having the filter to do the work also on new data ?
> - will it be possible to clear the filter and re-apply to all data ?
Yes, but this is a different feature. See the new
org.apache.pivot.collections.FilteredList class.
Re: Disabling tree nodes, table rows, and list items
Posted by Sandro Martini <sa...@gmail.com>.
Hi Greg,
I like this ... but only one question on it:
- will it be possible to apply also this (or more in general a filter)
filter to data added later, like a table containing rows, and then i
add other rows, having the filter to do the work also on new data ?
- will it be possible to clear the filter and re-apply to all data ?
Thanks,
Sandro
Re: Disabling tree nodes, table rows, and list items
Posted by Greg Brown <gk...@mac.com>.
Cool. It seems to be working out very well so far.
On Jul 29, 2009, at 2:15 PM, Todd Volkert wrote:
> Sorry for the late comment, but I'm very much in favor of this :)
>
> On Wed, Jul 29, 2009 at 12:34 PM, Greg Brown <gk...@mac.com> wrote:
>
>> 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 <gk...@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
>>>>>
>>>>
>>>>
>>>
>>
Re: Disabling tree nodes, table rows, and list items
Posted by Todd Volkert <tv...@gmail.com>.
Sorry for the late comment, but I'm very much in favor of this :)
On Wed, Jul 29, 2009 at 12:34 PM, Greg Brown <gk...@mac.com> wrote:
> 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 <gk...@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
>>>>
>>>
>>>
>>
>
Re: Disabling tree nodes, table rows, and list items
Posted by Greg Brown <gk...@mac.com>.
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 <gk...@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
>>
>
Re: Disabling tree nodes, table rows, and list items
Posted by Greg Brown <gk...@mac.com>.
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 <gk...@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
>
Re: Disabling tree nodes, table rows, and list items
Posted by Greg Brown <gk...@mac.com>.
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 <gk...@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
Re: Disabling tree nodes, table rows, and list items
Posted by Noel Grandin <no...@gmail.com>.
Great idea. Indexes are very hard to work with once you have widgets
that support sorting.
On 07/29/2009, Greg Brown <gk...@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
Re: Disabling tree nodes, table rows, and list items
Posted by Greg Brown <gk...@mac.com>.
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
>