GWT 编辑器框架 - ListEditor、删除项目、MVP 违规

发布于 2024-12-12 04:52:08 字数 1541 浏览 0 评论 0原文

public class PersonListEditor extends Composite implements IsEditor<ListEditor<Person, PersonListItemWidget>> {
    private static PersonListEditorUiBinder uiBinder = GWT.create(PersonListEditorUiBinder.class);
    interface PersonListEditorUiBinder extends UiBinder<Widget, PersonListEditor> {}

    private class Source extends EditorSource<PersonListItemWidget> {
        @Override
        public PersonListItemWidget create(int index) {
            PersonListItemWidget widget = new PersonListItemWidget();
            panel.insert(widget, index);
            return widget;
        }                   
    }   

    @UiField VerticalPanel panel;
    private ListEditor<Person, PersonListItemWidget> editor = ListEditor.of(new Source());

    public PersonListEditor() {
        initWidget(uiBinder.createAndBindUi(this));
    }

    @Override
    public ListEditor<Person, PersonListItemWidget> asEditor() {
        return editor;
    }
}

PersonListItemWidget 有一个删除按钮,单击此按钮时,我需要从列表中删除相关项目。

  1. 我可以让 PersonListEditor 监听项目小部件的通知(例如“我的删除按钮被单击”),但在这种情况下,我只会引用该小部件,而不是真正的Person 对象。我还可以添加一些逻辑来从面板项列表中获取相关小部件的索引,然后通过该索引获取 Person 对象,但这看起来很糟糕。

  2. 我可以让我的 PersonListItemWidget 成为一个 ValueAwareEditor,这样每个小部件都会知道它的 Person,但是 的整个想法ValueAwareEditor 对我来说看起来像是 MVP 违规,因为 Google 说视图层不应该知道模型,它应该只是“按钮”和“标签”。

这里正确的方法是什么?

public class PersonListEditor extends Composite implements IsEditor<ListEditor<Person, PersonListItemWidget>> {
    private static PersonListEditorUiBinder uiBinder = GWT.create(PersonListEditorUiBinder.class);
    interface PersonListEditorUiBinder extends UiBinder<Widget, PersonListEditor> {}

    private class Source extends EditorSource<PersonListItemWidget> {
        @Override
        public PersonListItemWidget create(int index) {
            PersonListItemWidget widget = new PersonListItemWidget();
            panel.insert(widget, index);
            return widget;
        }                   
    }   

    @UiField VerticalPanel panel;
    private ListEditor<Person, PersonListItemWidget> editor = ListEditor.of(new Source());

    public PersonListEditor() {
        initWidget(uiBinder.createAndBindUi(this));
    }

    @Override
    public ListEditor<Person, PersonListItemWidget> asEditor() {
        return editor;
    }
}

PersonListItemWidget has a Delete button and when this button is clicked, I need to remove the related item from the list.

  1. I can make PersonListEditor listen item widget's notifications (like "my delete button is clicked"), but in this case, I'll only have a reference to the widget and not a real Person object that I need in fact. I may also add some logic to get related widget's index from the list of panel items and then get Person object by that index, but that looks awful.

  2. I can make my PersonListItemWidget to be a ValueAwareEditor, so each widget will know its Person, but the whole idea of ValueAwareEditor looks like MVP violation for me since Google says that View layer shouldn't be aware of model and it should only be "buttons" and "labels".

What's the right approach here?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

放我走吧 2024-12-19 04:52:08

任何一种方法都可以。

MVP 并不是一成不变的(它甚至没有定义;它是由 Martin Fowler 创造的,但他退休了这个术语 支持两种更具体的模式),因此您只是违反了您给自己制定的规则。换句话说,编辑器框架作为一个整体可以被视为违反了 MVP:每个编辑器都知道模型,不一定知道它正在编辑的确切实例(如 ValueAwareEditorLeafValue) ,但至少是它所编辑的对象的种类

仅供参考,我们使用索引来做到这一点。更重要的是它保证可以工作,而不是它“看起来不错”(尽管它看起来不错显然会更好)。

Either approach is fine.

MVP is not set in stone (it's not even defined; it was coined by Martin Fowler but he retired the term in favor of two more specific patterns), so you're only violating the rules you gave to yourself. Put differently, the Editor framework as a whole can be seen as violating MVP: each editor know the model, not necessarily the exact instance it's editing (as with ValueAwareEditor or LeafValue), but at least the kind of objects it's an editor of.

FYI, we do it using indexes. It matters more that it's guaranteed to work than that it "looks good" (even though it's obviously better if it also looks good).

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文