Just to make sure I understand the change, this means that in order to (a)
get notified when the changes are actually saved to the model or (b) to
perform any validation, you'd subclass a stock editor to get hooks into
those window events?
If so, sounds good to me. I just want to make sure this change doesn't
reduce the usefulness of the stock editors.
-T
On Thu, Oct 14, 2010 at 2:38 PM, Greg Brown <gkbr...@mac.com> wrote:
> Not that I can see.
>
> On Oct 14, 2010, at 2:26 PM, Todd Volkert wrote:
>
> Is there any loss of functionality over the old API?
>
> On Thu, Oct 14, 2010 at 1:11 PM, Greg Brown <gkbr...@mac.com> wrote:
>
>> 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
>> >>>
>> >>
>> >
>>
>>
>
>
