On 12 nov, 20:23, PhilBeaudoin <
philippe.beaud...@gmail.com> wrote:
> Thanks Thomas for preempting me. Next time I'll try to be faster than
> you and conclude with "you can also wait a bit and see what Thomas
> will propose". ;)
>
> That being said, I believe it's important to point out that there are
> two point of views with respect to that problem. Some think nesting
> presenters and cascading their lifecycle methods is never required --
> that's the opinion of Thomas and the design team behind GWT 2.1 MVP.
> (Although I see you had to work around the problem somehow.) Others
> have been using nested presenters for a while and believe they make
> development easier -- that's the opinion of the GWTP design team.
Actually, I believe we should strongly try to disconnect activities
from MVP: Activities don't force you to do MVP, and you'll use MVP
beyond Activities.
I totally agree that nesting "presenters" (I call them "MVP
components") is needed in (almost) every application; but that doesn't
mean you have to nest activities.
And nothing in GWT proper tries to do anything to solve the issue of
nesting "presenters" (there's absolutely nothing in GWT proper related
to MVP actually; I refuse to call Activities an "MVP framework", it
has nothing to do with MVP in my opinion)
This leaves a lot of room for frameworks like GWT-P to go beyond
navigation (Places and Activities) and more into MVP.
I admit I haven't yet read it thoroughly, but my analysis (from the
little I know about GWT-P) would be that GWT 2.1 strongly decouples
navigation (places) from activities (things the user will do, through
activity mapper) from "view composition" (activities within
AcceptsOneWidget) from browser's history integration (place history
handler/mapper); whereas it's more "blurry" in GWT-P (it's even more
the case in Mvp4g AFAICT), where the "activity" tells "the framework"
when (as a result of some event dispatched on the bus) and where
(which "slot") it should be revealed.
Given my inexistent experience with GWT-P (I only read docs and
samples' code), I can very well be wrong though! And things being more
"blurry" is not necessarily a bad thing in practice (not my opinion
but YMMV); I mean, please do not read the above as criticisms; I'm by
no mean saying that GWT-P is a bad framework (quite the contrary, it
has a lot of traction, which to me is a sign).