Использование редакторов GWT со сложным вариантом использования

По сути, вы хотите, чтобы CompositeEditor обрабатывал случаи, когда объекты динамически добавляются или удаляются из иерархии редактора. Адаптеры ListEditor и OptionalFieldEditor реализуют CompositeEditor.

Если информация, необходимая для разных типов вопросов, принципиально ортогональна, то можно использовать несколько OptionalFieldEditor с разными полями, по одному для каждого типа вопроса. Это сработает, когда у вас всего несколько типов вопросов, но в будущем это не будет хорошо масштабироваться.

Другой подход, который будет лучше масштабироваться, заключается в использовании пользовательской реализации CompositeEditor + LeafValueEditor, которая обрабатывает полиморфную иерархию типа QuestionData. Выпадающий элемент пользовательского интерфейса type станет деталью реализации CompositeEditor. Когда выбран тип вопроса, редактор вызовет EditorChain.attach() с экземпляром подтипа QuestionData и под-редактором для конкретного типа. Вновь созданный экземпляр QuestionData следует сохранить для реализации LeafValueEditor.getValue(). Реализация CompositeEditor.setValue() просто создает подредактор для конкретного типа и вызывает EditorChain.attach().

FWIW, OptionalFieldEditor можно использовать с ListEditor или любым другим типом редактора.

Мы реализовали аналогичный подход (см. принятый ответ), и у нас он работает так.

Поскольку драйвер изначально не знает о простых путях к редактору, которые могут использоваться подредакторами, каждый подредактор имеет собственный драйвер:

public interface CreatesEditorDriver<T> {
    RequestFactoryEditorDriver<T, ? extends Editor<T>> createDriver();
}

public interface RequestFactoryEditor<T> extends CreatesEditorDriver<T>, Editor<T> {
}

Затем мы используем следующий адаптер редактора, который позволяет использовать любой подредактор, реализующий RequestFactoryEditor. Это наш обходной путь для поддержки полиморфизма в редакторах:

public static class DynamicEditor<T>
        implements LeafValueEditor<T>, CompositeEditor<T, T, RequestFactoryEditor<T>>, HasRequestContext<T> {

    private RequestFactoryEditorDriver<T, ? extends Editor<T>> subdriver;

    private RequestFactoryEditor<T> subeditor;

    private T value;

    private EditorDelegate<T> delegate;

    private RequestContext ctx;

    public static <T> DynamicEditor<T> of(RequestFactoryEditor<T> subeditor) {
        return new DynamicEditor<T>(subeditor);
    }

    protected DynamicEditor(RequestFactoryEditor<T> subeditor) {
        this.subeditor = subeditor;
    }

    @Override
    public void setValue(T value) {
        this.value = value;

        subdriver = null;

        if (null != value) {
            RequestFactoryEditorDriver<T, ? extends Editor<T>> newSubdriver = subeditor.createDriver();

            if (null != ctx) {
                newSubdriver.edit(value, ctx);
            } else {
                newSubdriver.display(value);
            }

            subdriver = newSubdriver;
        }
    }

    @Override
    public T getValue() {
        return value;
    }

    @Override
    public void flush() {
        if (null != subdriver) {
            subdriver.flush();
        }
    }

    @Override
    public void onPropertyChange(String... paths) {
    }

    @Override
    public void setDelegate(EditorDelegate<T> delegate) {
        this.delegate = delegate;
    }

    @Override
    public RequestFactoryEditor<T> createEditorForTraversal() {
        return subeditor;
    }

    @Override
    public String getPathElement(RequestFactoryEditor<T> subEditor) {
        return delegate.getPath();
    }

    @Override
    public void setEditorChain(EditorChain<T, RequestFactoryEditor<T>> chain) {
    }

    @Override
    public void setRequestContext(RequestContext ctx) {
        this.ctx = ctx;
    }
}

Наш пример подредактора:

public static class VirtualProductEditor implements RequestFactoryEditor<ProductProxy> {
        interface Driver extends RequestFactoryEditorDriver<ProductProxy, VirtualProductEditor> {}

        private static final Driver driver = GWT.create(Driver.class);

    public Driver createDriver() {
        driver.initialize(this);
        return driver;
    }
...
}

Наш пример использования:

        @Path("")
        DynamicEditor<ProductProxy> productDetailsEditor;
        ...
        public void setProductType(ProductType type){
            if (ProductType.VIRTUAL==type){
                productDetailsEditor = DynamicEditor.of(new VirtualProductEditor());

            } else if (ProductType.PHYSICAL==type){
                productDetailsEditor = DynamicEditor.of(new PhysicalProductEditor());
            }
        }

Было бы здорово услышать ваши комментарии.

Что касается вашего вопроса, почему конкретные данные подтипа не отображаются или не сбрасываются:

Мой сценарий немного отличается, но я сделал следующее наблюдение:

Привязка данных редактора GWT не работает, как можно было бы ожидать, с абстрактными редакторами в иерархии редакторов. SubEditor, объявленный в вашем QuestionDataEditor, имеет тип QuestionBaseDataEditor, и это полностью абстрактный тип (интерфейс). При поиске полей/подредакторов для заполнения данными/сбросом GWT берет все поля, объявленные в этом типе. Поскольку в QuestionBaseDataEditor нет объявленных подредакторов, ничего не отображается/не сбрасывается. Из отладки я узнал, что это происходит из-за того, что GWT использует сгенерированный EditorDelegate для этого абстрактного типа, а не EditorDelegate для конкретного подтипа, присутствующего в данный момент.

В моем случае все конкретные подредакторы имели одинаковые типы редакторов конечных значений (у меня было два разных конкретных редактора, один для отображения, а другой для редактирования одного и того же типа компонента), поэтому я мог сделать что-то вроде этого, чтобы обойти это ограничение:

interface MyAbstractEditor1 extends Editor<MyBean>
{
    LeafValueEditor<String> description();
}

// or as an alternative

abstract class MyAbstractEditor2 implements Editor<MyBean>
{
    @UiField protected LeafValueEditor<String> name;
}


class MyConcreteEditor extends MyAbstractEditor2 implements MyAbstractEditor1
{
    @UiField TextBox description;
    public LeafValueEditor<String> description()
    {
        return description;
    }

    // super.name is bound to a TextBox using UiBinder :)
}

Теперь GWT находит подредакторы в абстрактном базовом классе, и в обоих случаях я получаю заполненные и очищенные имена и описания соответствующих полей.

К сожалению, этот подход не подходит, когда конкретные подредакторы имеют разные значения в структуре вашего компонента для редактирования :(

Я думаю, что это ошибка генерации кода среды редактора GWT, которую может решить только команда разработчиков GWT.

Разве основная проблема не в том, что привязка происходит во время компиляции, поэтому будет привязываться только к QuestionDataProxy, поэтому не будет иметь привязок, специфичных для подтипа? В javadoc CompositeEditor говорится: «Интерфейс, который указывает, что данный редактор состоит из неизвестного количества подредакторов одного типа», чтобы исключить это использование?

На моей текущей работе я стремлюсь вообще избегать полиморфизма, так как СУБД его тоже не поддерживает. К сожалению, на данный момент у нас есть некоторые из них, поэтому я экспериментирую с фиктивным классом-оболочкой, который предоставляет все подтипы с определенными геттерами, чтобы компилятору было над чем работать. Хотя некрасиво.

Видели ли вы этот пост: http://markmail.org/message/u2cff3mfbiboeejr кажется, он соответствует действительности. .

Хотя меня немного беспокоит раздувание кода.

Надеюсь, это имеет какой-то смысл!