Very confusing aspect of MVP documentation!

[cri]

If you go to http://code.google.com/webtoolkit/doc/latest/DevGuideMvpActivitiesAndPlaces.html,
you'll see the note:

******************
Strictly speaking, MVP architecture is not concerned with browser
history management, but Activities and Places may be used with MVP
development as shown in this article. If you're not familiar with MVP,
you may want to read these articles first:

Large scale application development and MVP, Part I
Large scale application development and MVP, Part II
******************

This has sent two of our development teams off in the wrong direction.
I would be willing to venture that it has confused others as well.

The problem is that folks go into the Part I and II articles and
assume that GWT's MVP framework is being described and they go off and
duplicate it. But these articles don't describe GWT's *current* MVP
framework. Instead, the articles describe an approach to MVP that
preceded GWT official support.

Personally, I think that the reference to these articles should be
removed from the MVP documentation pages so folks won't go merrily
down the wrong path as others have.

[Xybrek]

What is the best MVP we can use with GWT? I am currently looking for
some lightweight MVP framework with some samples that will give me the
scaffoldings. With the connection to a database, through the RPC. I am
also trying to understand how login-logout fits the MVP scenario and how
when user is "logged in" the view is updated as data is modified in the
database. I cannot see any example having a RPC service which connects
to database, say through hibernate. - Xybrek

[cri]

I can only say that we've been very happy with the framework described
at http://code.google.com/webtoolkit/doc/latest/DevGuideMvpActivitiesAndPlaces.html,
aside from the issue I mentioned in my original post.

Regarding database access and login/logout - those seem separate from
MVP really.

On Jun 30, 3:35 pm, Xybrek <xyb...@gmail.com> wrote:
> On Friday, 01 July, 2011 04:13 AM, cri wrote:

> > If you go tohttp://code.google.com/webtoolkit/doc/latest/DevGuideMvpActivitiesAnd...,

[David Chandler]

Hi cri,

Thanks for pointing this out. Ironically, I added that note along with other changes just a few days ago in order to try to decouple MVP from Activities and Places. The GWT team, including Ray Ryan, doesn't think of Activities and Places as an MVP framework. It's a way to manage browser history and provides no base classes for presenters or views. MVP proper, as we're currently defining it, is not concerned with browser history management. Ray Ryan's talk in 09 and the previous MVP articles mentioned these concepts together, but they are not necessarily coupled, and we're trying to reflect that in the docs going forward.

At any rate, I hadn't noticed that the prior MVP articles discuss browser history management and I can see how this would lead you down the wrong path. We're working on updated versions, but in the mean time, I'll add notes to the history management sections pointing forward to Activities and Places instead.

Thanks again,

/dmc

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
David Chandler
Developer Programs Engineer, GWT+GAE
w: http://code.google.com/
b: http://googlewebtoolkit.blogspot.com/
t: @googledevtools

[cri]

Hmmmmmm.... Well, part of this is semantics I think. What exactly
constitutes MVP is the question. But regardless of that, it is true:

1) That one can use the combination of Views, ClientFactory,
Activities, Places, PlaceHistoryMapper, and ActivityMapper as
described at http://code.google.com/webtoolkit/doc/latest/DevGuideMvpActivitiesAndPlaces.html
to organize and automate Activity/View transition. We've done this on
several projects and have more in the pipeline.

2) The concepts/methods/classes described in the Part I and II
articles seem more manual and labor intensive and, though similar in
concept, are distinctly different in their detailed approach compared
to the above. We tried both with multiple real world projects and View/
Activities/Places/ActivityMapper/etc we've found to be superior.
Interestingly, we really not used them at all for history management.

3) One might argue that one is better than the other I guess but to
present them both, side by side, is just plain confusing to your user
base.

On Jun 30, 5:10 pm, David Chandler <drfibona...@google.com> wrote:
> Hi cri,
>
> Thanks for pointing this out. Ironically, I added that note along with other
> changes just a few days ago in order to try to decouple MVP from Activities
> and Places. The GWT team, including Ray Ryan, doesn't think of Activities
> and Places as an MVP framework. It's a way to manage browser history and
> provides no base classes for presenters or views. MVP proper, as we're
> currently defining it, is not concerned with browser history management. Ray
> Ryan's talk in 09 and the previous MVP articles mentioned these concepts
> together, but they are not necessarily coupled, and we're trying to reflect
> that in the docs going forward.
>
> At any rate, I hadn't noticed that the prior MVP articles discuss browser
> history management and I can see how this would lead you down the wrong
> path. We're working on updated versions, but in the mean time, I'll add
> notes to the history management sections pointing forward to Activities and
> Places instead.
>
> Thanks again,
> /dmc
>
>
>
>
>
>
>
>
>
> On Thu, Jun 30, 2011 at 4:43 PM, cri <chuck.irvine...@gmail.com> wrote:
> > I can only say that we've been very happy with the framework described
> > at

> >http://code.google.com/webtoolkit/doc/latest/DevGuideMvpActivitiesAnd...
> > ,

[Russ]

What I did was read through the MVP articles 1 & 2, read about the Activity and Places approach, tried coding a bit to get more familiar with the terminology and then started using GWT-Platform. With the new plugin it simplifies all of the cruft and confusion that is MVP..

Which would you rather believe in: A God that never answers you or a society that embraces you?

[cri]

I would imagine that GWT-Platform is better than GWT's native MVP (by
which I mean Activities/Places/ActivityMapper), otherwise it probably
wouldn't exist. The problem I have is that GWT-Platform isn't
supported by Google while their MVP is. Maybe GWT MVP isn't entirely
sufficient but it has worked well for us. It's not unreasonable to
assume that Google will enhance it in the future. What happens then
for development shops that have migrated to GWT-Platform and they are
tempted to switch back? They have existing code that uses another
framework and developers that are used to the non standard package.
Messy right?

On Jul 1, 4:00 am, Russ <10wattmindt...@gmail.com> wrote:
> What I did was read through the MVP articles 1 & 2, read about the Activity
> and Places approach, tried coding a bit to get more familiar with the
> terminology and then started using GWT-Platform. With the new plugin it
> simplifies all of the cruft and confusion that is MVP..
>
>
>
>
>
>
>
>
>
> On Thu, Jun 30, 2011 at 8:02 PM, cri <chuck.irvine...@gmail.com> wrote:
> > Hmmmmmm.... Well, part of this is semantics I think. What exactly
> > constitutes MVP is the question. But regardless of that, it is true:
>
> > 1) That one can use the combination of Views, ClientFactory,
> > Activities, Places, PlaceHistoryMapper, and ActivityMapper as
> > described at

> >http://code.google.com/webtoolkit/doc/latest/DevGuideMvpActivitiesAnd...

[David Chandler]

While it's true that gwt-platform is not supported or endorsed by Google, note that gwt-platform creator Philippe Beaudoin was invited to present at Google I/O this year (see the video at http://code.google.com/p/gwt-platform/). Also note that both gwt-platform and Activities and Places are built on the same core History support in GWT, which did not change with the 2.1 release and is unlikely to change. While GWT may continue to add new features in Activities and Places, I don't anticipate any changes that would break gwt-platform. The GWT team values the many 3rd party projects around GWT and generally tries to keep core GWT APIs as loosely coupled as possible in order to permit different development styles.

/dmc

b: http://turbomanage.wordpress.com/

[Brian Reilly]

To reiterate, GWT does not have a "native" MVP framework. Activities and Places are not directly related to MVP. The documentation is misleading on this point and, as David said, they're working on correcting that.

Some things to keep in mind:

1. MVP is a pattern. How that pattern is applied depends on the context of the problem.

2. Some techniques for applying MVP to GWT applications are described in the "LSAD and MVP, Part I" and "LSAD and MVP, Part II" articles.

3. Frameworks have been built to aid developers in applying MVP based on these techniques (though the introduction of a framework affects the context, which leads to multiple possible interpretations, hence multiple frameworks).

I'd suggest approaching MVP in this order. This is basically what Russ described doing, which ultimately led him to using GWTP. A good place to start is Ray Ryan's talk from Google I/O 2009.

-- Brian

On Fri, Jul 1, 2011 at 9:14 AM, cri <chuck.i...@gmail.com> wrote:

[Juan Pablo Gardella]

"which did not change with the 2.1 release and is unlikely to change". This is not common in reality. 

2011/7/1 David Chandler <drfib...@google.com>

[cri]

First, someone definitely *thought initially* that Views/ClientFactory/
Activities/Places/PlaceHistoryMapper/ActivityMapper described on the
GWT *MVP* documentation page constituted a framework that could be
*used* at least for MVP. And, indeed, it can be.

Secondly, to me and some others I'd guess, it seems superior in terms
of effort required than what is described in the "Part I and II"
articles. We have a number of people here that have used both and
there is agreement on this. However, I'm sure there are some relevant
pros and cons.

Finally, the original point was not that one is better than the other,
but that their close and unexplained juxtaposition had confused a few
folks, (blush) including present company. I think a lot of people are
going to think that what is described in the "Part I and II" articles
are examples of what follows them on the MVP documentation page. If
the documentation could be amended to make it clear that this is not
the case, that would be great!

Thanks for GWT!

[Thomas Broyer]

Le vendredi 1 juillet 2011 18:12:45 UTC+2, cri a écrit :

First, someone definitely *thought initially* that Views/ClientFactory/
Activities/Places/PlaceHistoryMapper/ActivityMapper described on the
GWT *MVP* documentation page constituted a framework that could be
*used* at least for MVP. And, indeed, it can be.

Secondly, to me and some others I'd guess, it seems superior in terms
of effort required than what is described in the "Part I and II"
articles. We have a number of people here that have used both and
there is agreement on this. However, I'm sure there are some relevant
pros and cons.

That's because all of them talk about history management, not only MVP. The *MVP* part is only the View/Display interface and the handlers vs. the Presenter/Delegate interface (people use different names for similar those things); everything else is not part of the MVP *pattern*.

[ungarida]

I agree with cri, probably the documentation should be reviewed and
updated to GWT 2.3.
Reading all the stuff I miss the big picture, should be useful some
schemes that summarize things.

Anyway I wil try to implement a complete example on AppEngine using
Activity, Places, MWP, RequestFactory, Editor and so on.
I will need help of everyone and code review :)

[ungarida]

I open the project
http://code.google.com/p/gwt-meeting-room/

[Elhanan Maayan]

if i may add my 2 cents, i think that Places-Activities-Framework(PAF? anyone? , each time somebody adds another component, and it's beginning to be absurd, so why not go for PAF :) ). should NOT be considred as an MVP framework, nor should be considered as history handling one.
for example our CTO declared there where will NO back button functionality thus no history to be managed (advocating that "regular" I.T apps do not have back button as well), however i'm still promoting it's use not as MVP or history but as a FLOW framework, allowing me to clearly define points of interests in regards to WHERE should a user go and WHAT a user can do when he gets there, something similar to webflow i would think. is see nothing in GWT that currently supports that.
where as the presenter is concerned i found it cumbersome, why would i restrict to redefine an inner class with rigid interfaces only to separate myself from other parts, all i REALLY wanna do is to send messages from the view to what ever is using it. using Custom events (but with an abstract Event pattern i wrote here earlier) i avoid the boiler plate coding that comes with and earn a much more flexible interface between layers.
 

On Sun, Jul 3, 2011 at 6:56 PM, ungarida <unga...@gmail.com> wrote:

I open the project
http://code.google.com/p/gwt-meeting-room/