On Apr 22, 9:27 am, interdev <[email protected]> wrote: > Hello everyone, > have you seen the new MVP Architecture article from google > ?http://code.google.com/webtoolkit/articles/mvp-architecture-2.html
First, I only read it quickly, I didn't download and looked at the sample project. > 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 ? Not strictly necessary but it makes things simpler in the end (from experience: I initially followed the same approach as Ray Ryan explained at Google I/O 2009 and switch to a very similar approach to this Part II a few weeks ago; it really gives you more flexibility and makes the code, including unit tests, much easier to read). In my project, the interfaces are all defined within the presenter class, and the presenter interface (which I call Listener in my code) is implemented by a private inner class. But the overall approach is the same. > 2- when google wants to address problem of Nested/Layered presenters ? > header/body/footer, and body having its own dockpanellayout structure. There are many ways of approaching the problem; just like with MVP (the Display interface exposing HasXxxHandlers as in Part I vs. the View and Presenter interfaces as in Part II). In our app, in effect, each "parent presenter" also plays the role of "app controller"; but because we have the presenter/view dichotomy, the view exposes setSomeWidget(...) methods that the presenter calls; e.g. setHeader(...), setBody(...), setFooter(...). > 3- what do you think of "presenter.go(container)" ? We do it the other way around: our presenters have a getView() method and the parent calls container.add((Widget) child.getView()). This is actually split between the presenter and the view, see above: view.setHeader(childPresenter.getView()) in the presenter, and containerWidget.add((Widget) child) in the view. The only "issue" with presenter.go(container) is that container must be a "simple" container, which means that when it's meant to be a dock (layout) panel, tab panel, or some other complex panel (or an absolute panel and you want to add with coordinates), you actually have to add a SimplePanel first and pass it as the "container" to the go() method. Otherwise, I can't see a problem with presenter.go(container). > and navigation/ > history token inside multiple IF statements ? I'm using a very similar approach as the one in bikeshed: http://code.google.com/p/google-web-toolkit/source/browse/trunk/bikeshed/src/com/google/gwt/app/place/ > i think these are more serious to address than introducing an > additional view interface which has an inner interface ! But they highly depends how your app is organized re. "navigation". For instance, in Google Wave, there's no "switching of views" in the "app controller", though there obviously is at lower levels. And given how the history token is built, there probably isn't "history token inside multiple IF statements". > 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 mean what's explained in the "dumb view" sections? How is it related to any ORM/persistence layer/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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
