MVP presenter interface: use HasWidgets or AcceptsOneWidget ?

[Francois Marot]

Hi all,

I'll have to set the basics for a in-house framework and can't make my mind on the basic Presenter interface. Is it better to use HasWidgets or AcceptsOneWidget ? This would lead to:


public interface Presenter {
  public void go(final HasWidgets container);
}

or

public interface Presenter {
  public void go(final AcceptsOneWidget container);
}

The former is more generic I think but you always have to think about adding the line container.clear() in your implementations. In the latter, it's more straightforward (container.setWidget(myView) ) and it is clearer as it's enforce the responsibility on the depper Presenter to provide only one widget. It's his responsability to group every widget into one container before calling setWidget().
I prefer the latter but it seems that more components implement HasWidgets so in the end the former would be easier to developp. What do you think ?

For the record, I was forced to develop a wrapper (HasWidgetsToAcceptsOneWidgetWrapper) in order to pass the RootLayoutPanel to my first Presenter using the latter method. Here's the dirty code:
public class HasWidgetsToAcceptsOneWidgetWrapper implements AcceptsOneWidget {
    private HasWidgets wrapped;

    public HasWidgetsToAcceptsOneWidgetWrapper(HasWidgets wrapped) {
        this.wrapped = wrapped;
    }

    public void setWidget(IsWidget widgetToAdd) {
        wrapped.clear();
        wrapped.add(widgetToAdd.asWidget());
    }

}

[Thomas Broyer]

I suppose from that last comment that your Presenter interface is seen by objects manipulating the "MVP component", i.e. it's not the presenter "as seen by the view".

Anyway, in either case, it shouldn't be the responsibility of the component to display itself, but rather the responsibility of some sort of conductor/manager/controller. So just have your presenter implement IsWidget and you're done.

As an added bonus, because it's an IsWidget, you can use it anywhere a widget is expected/accepted, including in UiBinder templates.

To answer your question though, it strikes me as odd to use HasWidgets here: you really want to give your component the power (and responsibility) to clear() its container? or add() more than one widget to it? or inspect (via interator()) the widgets already contained in it and possibly remove() some of them? (how about removing all but the first 2, adding itself and adding the removed widgets back in, to simulate an insert?)

No, really, you don't want HasWidgets, AcceptsOneWidget is the way to go; or IsWidget as I said above.

But all of this really depends how you're intending to use your "Presenter" interface. I'm not familiar with that approach (first and foremost: I see MVP as an implementation detail, the outside world simply deals with a "component" and it doesn't matter whether it uses MVP internally or not).

[Francois Marot]

Hi Thomas and thanks for your response.
You're right, I'm not talking about how the View sees its Presenter but how the Presenter is seen from "what's above him" (in my case, usually another Presenter, my Presenters are nested). From what I understood (and pretty like it !) from the Google MVP Tutorial the Presenter is usually not a component (or Widget) in itself but puts its component (its View) inside the container that is given to him in its go(...) method. So I thought what I am doing was pretty classic MVP...
Nevertheless, I totally agree that the solution using the "HasWidgets" type in the go(...) method may lead the Presenter to have too much knowlege of the internals. The drawback: it seems that more components implement the HasWidgets type rather than the AcceptsOneWidget one. I wouldn't want to have to force every class to reuse my dirty wrapper (see HasWidgetsToAcceptsOneWidgetWrapper). Anyone with prior experience ?

[Thomas Broyer]

On Friday, September 7, 2012 2:43:51 PM UTC+2, Francois Marot wrote:

Hi Thomas and thanks for your response.
You're right, I'm not talking about how the View sees its Presenter but how the Presenter is seen from "what's above him" (in my case, usually another Presenter, my Presenters are nested). From what I understood (and pretty like it !) from the Google MVP Tutorial the Presenter is usually not a component (or Widget) in itself but puts its component (its View) inside the container that is given to him in its go(...) method. So I thought what I am doing was pretty classic MVP...
Nevertheless, I totally agree that the solution using the "HasWidgets" type in the go(...) method may lead the Presenter to have too much knowlege of the internals. The drawback: it seems that more components implement the HasWidgets type rather than the AcceptsOneWidget one. I wouldn't want to have to force every class to reuse my dirty wrapper (see HasWidgetsToAcceptsOneWidgetWrapper). Anyone with prior experience ?

The Wave guys: http://www.google.com/events/io/2010/sessions/gwt-continuous-build-testing.html

(search for "Creating a new dynamic sub component" in the slides; and you'll note that the "parent view" then adds the "child view" to it and handles layout, not the other way around; there's no go(AcceptsOneWidget) method, instead each view would implement IsWidget)

[fg]

Hi Thomas,

first and foremost: I see MVP as an implementation detail, the outside world simply deals with a "component" and it doesn't matter whether it uses MVP internally or not).

Could you possibly elaborate on your remarks above? Might you mean the ultimate "component" should be constructed as if it had internal MVP attributes below? Thanks a lot.

class C {

M m;

V v;

P p;

...

}