ISIS: переход от устаревшего @Action (invokeOn = ...) к @Action (associateWith = ...) - PullRequest
0 голосов
/ 30 января 2019

Я работаю над проектом, использующим ISIS 1.16.2.У меня есть суперкласс, называемый ConfigurationItem, который имеет некоторые общие свойства (name, createdTimestamp и т. Д.).Например, у него есть метод действия удаления, помеченный @Action(invokeOn = InvokeOn.OBJECT_AND_COLLECTION, ...), который нужно вызывать из подробного представления сущностей, а также из представлений коллекции с полями выбора.

Пример:

public class ConfigurationItem {

    @Action(
            invokeOn = InvokeOn.OBJECT_AND_COLLECTION,
            semantics = SemanticsOf.NON_IDEMPOTENT_ARE_YOU_SURE,
            domainEvent = DeletedDomainEvent.class)
    public Object delete() {
        repositoryService.remove(this);
        return null;
    }

    // ...
}

public class ConfigurationItems {

    @Action(semantics = SemanticsOf.SAFE)
    public List<T> listAll() {
        return repositoryService.allInstances(<item-subclass>.class);
    }

    // ...
}

Это работает довольно хорошо, но аннотация invokeOn теперь устарела.JavaDoc говорит, что нужно переключиться на @Action(associateWith="..."), но я не знаю, как передать семантику 'InvokeOn', так как у меня нет поля коллекции для справки.Вместо этого у меня есть только коллекция объектов, возвращаемых действием извлечения базы данных.

Мой вопрос: Как перенести устаревшую семантику @Action(invokeOn=...) в новую концепцию @Action(associateWith="...") для коллекциивозвращать значения без поля с резервным свойством?

Заранее спасибо!

1 Ответ

0 голосов
/ 31 января 2019

Хороший вопрос, это, очевидно, недостаточно хорошо объяснено в документации Apache Isis.

@Action(invokeOn=InvokeOn.OBJECT_AND_COLLECTION) всегда был чем-то вроде клочья, потому что он включает в себя действие против автономной коллекции (то есть список объектов, возвращаемых из предыдущего запроса).Нам это не нравится, потому что нет «единственного» объекта для вызова действия.

Когда мы реализовали эту функцию, поддержка моделей представлений была далеко не такой всеобъемлющей, как сейчас.Итак, наша рекомендация теперь состоит в том, чтобы вместо того, чтобы возвращать пустую автономную коллекцию, вместо этого обернуть ее в модель представления, которая содержит коллекцию.

Затем модель представления дает нам единственную цель для вызова некоторого поведения;идея заключается в том, что ответственность за просмотр всех выбранных элементов лежит на модели представления, а затем на них запускается действие.

С вашим кодом мы можем ввести SomeConfigItems в качестве модели представления:

@XmlRootElement("configItems")
public class SomeConfigItems {

    @lombok.Getter @lombok.Setter
    private List<ConfigurationItem> items = new ArrayList<>();

    @Action(
        associateWith = "items",  // associates with the items collection
        semantics = SemanticsOf.NON_IDEMPOTENT_ARE_YOU_SURE,
        domainEvent = DeletedDomainEvent.class)
    public SomeConfigItems delete(List<ConfigurationItem> items) {
        for(ConfigurationItem item: items) {
           repositoryService.remove(item);
        }
        return this;
    }
    // optionally, select all items for deletion by default
    public List<ConfigurationItem> default0Delete() { return getItems(); }

    // I don't *think* that a choices method is required, but if present then 
    // is the potential list of items for the argument
    //public List<ConfigurationItem> choices0Delete() { return getItems(); }
}

и затем измените действие ConfigurationItems, чтобы вернуть эту модель представления:

public class ConfigurationItems {

    @Action(semantics = SemanticsOf.SAFE)
    public SelectedItems listAll() {
        List<T> items = repositoryService.allInstances(<item-subclass>.class);
        return new SelectedItems(items);
    }
}

Теперь, когда у вас есть модель представления для представления выходных данных, вы, вероятно, найдете другие вещи, которые можно сделатьс ним.

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

...