Re: Reordering items in ListEditor

Thomas, in your opinion, would this problem be worth a patch? What is the status of editor framework regarding GWT 3?

If editors should be evolved further, I could propose a patch for this. I don't like exposing ListEditorWrapper in getList method signature, so that would call for a bit more thinking, but over all, patch would be rather small.

On Friday, March 10, 2017 at 10:56:49 AM UTC+1, Thomas Broyer wrote:

On Friday, March 10, 2017 at 10:13:44 AM UTC+1, Gordan Krešić wrote:

I'm editing List of ValueProxies and I'm trying to implement reordering of items (move to front, move to back, move up, move down the list). Since ListEditors work by reflecting change in underlying List and List interface does not support atomic "move" operation for item reordering, my only option is to first remove item from List and then add elements at desired index. So far so good, but in ListEditor, underlying List contains unflushed values so when I reinsert them, newely created editors get old values and I loose changes made before reordering took place.

Since flushing ListEditor before remove/add didn't seem as a good idea (breaks editor contract and I would have to propagate Driver down the editors hierarchy) I've ended up cloning ListEditor and its underlying ListEditorWrapper to my own DynamicListEditor and DynamicListEditorWrapper (couldn't even extend them, because relevant members are private).

In DynamicListEditorWrapper I've added one additional method to reorder both elements in underlying list and their corresponding editors in-place:

public void move(int fromIndex, int toIndex) {

workingCopy.add(toIndex, workingCopy.remove(fromIndex));

editors.add(toIndex, editors.remove(fromIndex));

for (int i = Math.min(fromIndex, toIndex), j = Math.max(fromIndex, toIndex); i <= j; i++)

editorSource.setIndex(editors.get(i), i);

}

In DynamicListEditor I've used that new wrapper and exposed it in getList method:

public DynamicListEditorWrapper<T, E> getList() {

return list;

}

Now I'm able to move item one place up the list by calling:

int currIndex = /* get current index, easy */;

if (currIndex == 0)

return;

listEditor.getList().move(currIndex, currIndex - 1);

I works, but I can't shake off the feeling that I'm over-engineering it and that there is a better (simpler) way for doing this. After all, Lists are ordered collections and editing that order should not be this complicated.

Any advice?

I dug into one of our apps and something I've seen is that we did the same kind of things except "around" ListEditor rather than duplicating it:

The widget is a ValueAwareEditor<List<T>>, has a child @Path("") ListEditor<T, E> and has *two* fields of type List<T>: the actual value being edited (called 'value'), and a copy of it to track changes (called 'list').

Our flush() and setValue() from ValueAwareEditor are:

  @Override

  public void flush() {

    this.value.clear();

    this.value.addAll(this.list);

  }

  @Override

  public void setValue(List<P> value) {

    this.value = value;

    this.list.clear();

    this.list.addAll(value);

  }

The other methods are no-ops.

And our moveUp/moveDown manipulate the widgets/editors themselves (I note that the widgets aren't IsEditor<T>, but directly Editor<T>, if that makes a difference) and the 'list' (but not 'value').

In other words, we only manipulate 'value' on setValue/flush, which I believe is to not break the editor contract.

I can't tell if this was over-engineered as well or not, or hackish (probably a bit), as that code is nearly 6 years old already.

(btw, instead of "workingCopy.add(toIndex, workingCopy.remove(fromIndex))" we use "Collections.swap(this.list, index, newIndex)"; probably does the same but is more readable; and we limit ourselves to a delta of -1/1)

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.