On Thu, Apr 22, 2010 at 3: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 > > 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 ? > It's not necessary, but it's something we've learned from the Wave team, and internally find more flexible and easy to test. There are many ways to wire up your views and presenters, and the technique that you use is largely driven by the application that you are developing. For example, while Ad Words and Wave extensively use the MVP pattern, the Ad Words architecture is more inline with the techniques discussed in part I, and Wave with part II. That said, the one characteristic that they both share is the need to test as much as they possible can with vanilla JRE tests. Nothing against GwtTestCase, but we all know it's slow. > 2- when google wants to address problem of Nested/Layered presenters ? > header/body/footer, and body having its own dockpanellayout structure. > We use the technique described in part II. Composite views are responsible for instantiating their own children, and making them available for the parallel composite presenters. > > 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 ? > If you're referring to the ColumnDefinitions, we know they'll scale. One, it requires minimal widget overhead and is fast. No more embedding hundreds of widgets within a table. Two, it's extensible, and testable. As your model grows, your ColumnDefinitions grow, not your views. ColumnDefinitions are quite trivial, the bulk of the code dedicated to generating HTML, and don't require a GwtTestCase. > > -- > 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]<google-web-toolkit%[email protected]> > . > For more options, visit this group at > http://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 [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.
