Hi,

originally the MVP pattern was design for separating the view from its
logic and the model it is displaying (as the MVC). Since the arriving
of UIBinder I found the word View misused. Actually, strictly speaking
the View is contained in the ui.xml file and the "Controller" is the
corresponding java file which is implementing the corresponding logic
and instanciation. This file merely represents a kind of Controller.
The Presenter used in this tutorial is (for me) nothing more than a
ControllerProvider which enable the ability to provide differents
implementations of the view logic.

What I'm founding strange is the fact that their are using the same
acronym (MVP) for two differents approaches :
 - first one was Presenter centered as the abstraction was done on
Display and aggregation were done against the presenter
 - second one was Display AND Presenter centered as the abstraction is
done on Presenter and Display the both referencing each other.

But this approach is mainly due to the fact that UIBinder is removing
a lot of boiler plate code from event handling (and first MVP tutorial
was not using it), but in the same way UIBinder tends people to adapt
the original MVP pattern to be able to use all its power !
That why there is so much reflexion to mix UIBinder and MVP together.

cheers



On Apr 22, 9:27 am, interdev <jason.ved...@gmail.com> wrote:
> Hello everyone,
> have you seen the new MVP Architecture article from google 
> ?http://code.google.com/webtoolkit/articles/mvp-architecture-2.html
>
> they have changed the structure slightly, instead of having a View and
> a Presenter which has an inner Interface (Display), aside from the
> UiBinder part, they now have a View interface which has an inner
> Presenter interface !
>
> 1- what do you all think ? are these yet another level of abstraction/
> indirection necessary ?
>
> 2- when google wants to address problem of Nested/Layered presenters ?
> header/body/footer, and body having its own dockpanellayout structure.
>
> 3- what do you think of "presenter.go(container)" ? and navigation/
> history token inside multiple IF statements ?
>
> i think these are more serious to address than introducing an
> additional view interface which has an inner interface !
>
> 4- what do you think of DTO solution presented in the article, is it
> scalable ? do you follow it or stick with your twig, gilead
> framework ?
>
> --
> 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-web-tool...@googlegroups.com.
> To unsubscribe from this group, send email to 
> google-web-toolkit+unsubscr...@googlegroups.com.
> For more options, visit this group 
> athttp://groups.google.com/group/google-web-toolkit?hl=en.

-- 
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-web-tool...@googlegroups.com.
To unsubscribe from this group, send email to 
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/google-web-toolkit?hl=en.

Reply via email to