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
> >>>
> >>
> >
>
>
