Mailing-List: contact dev-help@pivot.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@pivot.apache.org
Received-SPF: softfail (nike.apache.org: transitioning domain of
 gkbrown@mac.com does not designate 206.46.173.17 as permitted sender)
Subject: Re: RowEditor and db
MIME-version: 1.0 (Apple Message framework v1081)
Content-type: text/plain; charset=us-ascii
From: Greg Brown <gkbrown@mac.com>
In-reply-to: <D04D2793-8C88-4D34-BB0B-5071AD6CACAB@mac.com>
Date: Thu, 14 Oct 2010 13:11:27 -0400
Cc: user@pivot.apache.org
Content-transfer-encoding: quoted-printable
Message-id: <5E09C8CA-ADCF-4965-A8B3-1105DB5C4303@mac.com>
References: <AANLkTim7nJfrZ--r+F5-ynUf6wpWyRRoAXiyHpSeJUO=@mail.gmail.com>
 <FCF7D1B5-C9DE-408F-84F5-320E715A1E82@mac.com>
 <AANLkTinp552yiZA2cTL9ezJZaJ5VuhPCtvKY00j1Qd4F@mail.gmail.com>
 <CDAA8D4B-6776-4DEF-B088-2594ADD3BF01@mac.com>
 <44A7F58B-0C48-4F55-94A8-341D1070A678@mac.com>
 <D04D2793-8C88-4D34-BB0B-5071AD6CACAB@mac.com>
To: dev@pivot.apache.org

I just validated this approach with TableView.RowEditor. I ran into some =
minor issues with non-text cell editors, but I don't think they are =
related to the API change (probably just some error in my code - I =
ported the class pretty quickly). Todd can probably resolve them pretty =
quickly.

At this point, I'm pretty confident that this change is worth making. =
Any additional comments?


On Oct 14, 2010, at 12:32 PM, Greg Brown wrote:

> FYI, I have applied this approach to TreeView and it seems to work =
fine - I'll try updating TableView next.
>=20
> On Oct 14, 2010, at 11:56 AM, Greg Brown wrote:
>=20
>> I just looked into this a bit more closely. I definitely see what you =
mean about the ease of use issue - I think the current editor API is =
probably a bit more complex than it needs to be.
>>=20
>> I just prototyped a simpler version for ListView.ItemEditor that I =
think will also work for TableView and TreeView (as well as ListButton =
and Spinner, which don't currently support editors but should). The =
updated interface consists of a single method:
>>=20
>> public interface ItemEditor {
>>   public void edit(ListView listView, int itemIndex);
>> }
>>=20
>> This simplified interface obviously makes it much easier to implement =
custom editors. The default ListViewItemEditor class now extends Window =
and implements ListView.ItemEditor (see attached). The implementation of =
the edit() method simply sets up the editor and calls the base open() =
method to show the popup. It overrides close() to update the list data.=20=

>>=20
>> By default, the editor does not perform any validation. However, this =
can easily be applied at the application level by overriding the =
close(boolean) method. This approach is consistent with other means of =
collecting user input in a Pivot application (e.g. dialogs and sheets), =
which also often override close() to perform validation.=20
>>=20
>> An application could also override close() to perform DB updates. =
Alternatively, this could be done in response to change events fired by =
the model. Which approach is best depends on the requirements of the =
application.
>>=20
>> TableView's editor interface would look like this:
>>=20
>> public interface RowEditor {
>>   public void edit(TableView tableView, int rowIndex, int =
columnIndex);
>> }
>>=20
>> and TreeView's like this:
>>=20
>> public interface NodeEditor {
>>   public void edit(TreeView treeView, Path path);
>> }
>>=20
>> Comments are welcome.
>>=20
>> G
>>=20
>> On Oct 14, 2010, at 10:08 AM, Greg Brown wrote:
>>=20
>>>> After writing this, I think I should rather write a jira ticket!
>>>=20
>>> That's a good idea. It sounds like you might have some good ideas as =
to how the editing process could be improved, and JIRA is the best way =
to track issues like this.
>>>=20
>>> G
>>>=20
>>=20
>=20