[ovirt-devel] Frontend - please avoid putting business logic into Views
Vojtech Szocs
vszocs at redhat.com
Wed Dec 3 17:17:58 UTC 2014
Hi guys,
our GWT frontend generally follows the Model-View-Presenter
design pattern via GWT-Platform MVP module [1].
[1] https://github.com/ArcBees/GWTP/wiki/Getting-started
Presenters/PresenterWidgets should be the ones containing
the business logic. Views should only contain simple logic
to perform necessary UI updates etc.
Consider the following example of imaginary "Foo" dialog:
// inside FooPopupView.java
@Override
public void edit(SomeModel model) {
// this is OK!
driver.edit(model);
// please DON'T do this!
model.getSomeAttribute().getEntityChangedEvent().addListener(...);
}
There are two main reasons why to avoid adding listeners
to given model (i.e. SomeModel) inside View.edit() method:
1, MVP pattern encourages putting business logic into
Presenter (reflecting Presenter's responsibility)
2, View.edit()'s responsibility is to populate UI from
model data, and can be potentially called multiple
times!
Following example shows the "correct" (MVP-ish) way:
// inside FooPopupPresenterWidget.java
public interface ViewDef extends ... {
// in your listener, you can use getView().doSomething()
void doSomething();
}
@Override
public void init(SomeModel model) {
// listeners are added only once, as they should!
model.getSomeAttribute().getEntityChangedEvent().addListener(...);
}
This applies to both PresenterWidgets (typically dialogs)
and "regular" Presenters (typically main/sub tabs etc).
Also, please avoid explicit View impl. type casts inside
Presenters/PresenterWidgets:
// inside FooPopupPresenterWidget.java
// please DON'T do this!
((FooPopupView) getView()).doSomething();
// you should use this!
getView().doSomething();
Just modify the ViewDef interface to contain methods you
need to invoke on the View. Please remember that ViewDef
is THE interface between Presenter and View. Please avoid
referencing specific View implementation inside Presenter.
Let me know if you have any questions.
Regards,
Vojtech
More information about the Devel
mailing list