Isn't the Activities and Places model violating the MVP pattern?

[Behi]

Just had a look at the source code for the "Tutorial-hellomvp-2.1"
example and noticed the following view interface:

public interface HelloView extends IsWidget
{
void setName(String helloName);
void setPresenter(Presenter listener);

public interface Presenter
{
void goTo(Place place);
}
}

Isn't this in violation with the MVP pattern as the view should not
depend-on/have-a-reference-to to the Presenter?

[Thomas Broyer]

If you value theory and "purity" more than pragmatism and productivity, then yes, it probably violates the pattern, as it doesn't use the observer pattern. But note that even Martin Fowler warns about the "dangers" of the observer pattern: http://martinfowler.com/eaaDev/OrganizingPresentations.html#observer-gotchas

For a great presentation of "pragmatic MVP", have a look at http://www.google.com/events/io/2010/sessions/gwt-continuous-build-testing.html

[Behi]

Thanks for the response. I shall have a look at those links later
tonight.

> If you value theory and "purity" more than pragmatism and productivity, then
> yes, it probably violates the pattern, as it doesn't use the observer
> pattern.

My concern is not that passing the presenter to the view is a bad
thing per se, but that when doing so we can not say we have
implemented the MVP pattern anymore, as in each design pattern the
collaborators, their responsibilities, and the relationships between
them are set in stone so that when I say that Foo is Singleton it is
universally clear what Foo is. In other words, design patterns make it
possible to communicate ideas clearly as long as they have a clear and
universal definition.

So maybe we should call this design pattern something else. However
looks like there's not a clear definition of MVP available anyway, as
for example in Dolphin Smalltalk it means something different to
ASP.NET.

Now back to passing the Presenter to the View, what methods of the
presenter should be exposed to the view? Should the view still be
ignorant about the model? or should we expose
PresenterImpl.getContacts(): ArrayList<Contact> to the view as well?

[Thomas Broyer]

On Tuesday, September 27, 2011 2:45:20 AM UTC+2, Behi wrote:

Thanks for the response. I shall have a look at those links later
tonight.

> If you value theory and "purity" more than pragmatism and productivity, then
> yes, it probably violates the pattern, as it doesn't use the observer
> pattern.

My concern is not that passing the presenter to the view is a bad
thing per se, but that when doing so we can not say we have
implemented the MVP pattern anymore, as in each design pattern the
collaborators, their responsibilities, and the relationships between
them are set in stone so that when I say that Foo is Singleton it is
universally clear what Foo is. In other words, design patterns make it
possible to communicate ideas clearly as long as they have a clear and
universal definition.

So maybe we should call this design pattern something else. However
looks like there's not a clear definition of MVP available anyway, as
for example in Dolphin Smalltalk it means something different to
ASP.NET.

Exactly, there's actually no "MVP" pattern. The agreed-upon definition of MVP is that you have M↔P↔V, vs. the M→V→C→M triangle of MVC (which is not to be confused with the "web MVC" pattern popularized by Ruby on Rails and used in ASP.NET).

 

Now back to passing the Presenter to the View, what methods of the
presenter should be exposed to the view? Should the view still be
ignorant about the model? or should we expose
PresenterImpl.getContacts(): ArrayList<Contact> to the view as well?

Go read the slides I linked to earlier ;-)

I didn't do it that way personally, but I'll try to stick with that approach from now on. Basically, all interfaces are "push-oriented": the presenter pushes data to the view and/or otherwise control how the view should appear and behave, and the view "pushes" changes to the presenter in response to user events.

Of course, this is again only theory, as the use of the Editor framework and/or cell widgets (CellTable, CellList) blurs the presenter/view line and changes their interaction a bit (the editor framework is based on the Flow Synchronization pattern, whereas the above idea is a bit more like Observer Synchronization –despite not using events and observers per se–)

One thing is clear (to me at least): there's absolutely no reason that your view is ignorant about the model, particularly if it makes things easier to code and maintain, and doesn't decrease testability.

That being said, I'm a supporter of a "do things like you feel they best suit your needs" approach rather than "try to stick to the patterns as closely as possible", so don't take my words above for granted.