pivot-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Brown <gkbr...@mac.com>
Subject Re: RowEditor and db
Date Thu, 14 Oct 2010 17:11:27 GMT
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.
> 
> On Oct 14, 2010, at 11:56 AM, Greg Brown wrote:
> 
>> 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.
>> 
>> 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:
>> 
>> public interface ItemEditor {
>>   public void edit(ListView listView, int itemIndex);
>> }
>> 
>> 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. 
>> 
>> 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. 
>> 
>> 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.
>> 
>> TableView's editor interface would look like this:
>> 
>> public interface RowEditor {
>>   public void edit(TableView tableView, int rowIndex, int columnIndex);
>> }
>> 
>> and TreeView's like this:
>> 
>> public interface NodeEditor {
>>   public void edit(TreeView treeView, Path path);
>> }
>> 
>> Comments are welcome.
>> 
>> G
>> 
>> On Oct 14, 2010, at 10:08 AM, Greg Brown wrote:
>> 
>>>> After writing this, I think I should rather write a jira ticket!
>>> 
>>> 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.
>>> 
>>> G
>>> 
>> 
> 


Mime
View raw message