There is quite a serious collision between the MVP pattern and the (super cool) UiBinder.
Presenters don't know what their concrete view is, all they know is the view interface has a asWidget() method. This seems like a logical separation. MVP says "presenters shouldn't know HOW they are visually displayed". Since this is the real world, you will probably want to have a childView added to your parentView - this get's messy with UiBinder.... Presenters can only obtain either the childView's interface... childPresenter.getView(); *//return's only interface type, not a widget!* Or, it can get a plain old widget via asWidget().... childPresenter.getView().asWidget();*//return's just the type "Widget".* Thus, the parentView can only be provided with a "Widget" via childPresenter.getView().asWidget(). Inturn, that's all you can specify in the ParentViewui.xml, i.e. <g:Widget uiField="childView">, the ParentView.ui.xml would look like: <g:SomePanel> *<g:Widget uiField="childView"/> <!-- Can't specify a concrete Widget type here!!!! -->* </g:SomePanel> You also need this in the ParentView.java @UiField(provided=true) Widget childView; //Can't specify a concrete Widget type here!!!! Because Gin has it's limit's and there's very limited runtime options with UiBinder, you end up writing a lot of BoilerPlate code "providing" the child widgets, plus you have to work with just "Widget" type's everywhere. Both of which are BAD and really do make development difficult.... and don't forget you can't call uiBinder.createAndBind until all widget's have been provided. Thanks for reading. --AH On Tue, Apr 27, 2010 at 10:37 PM, Mike <[email protected]> wrote: > I'd like to chime in as well... > > Since the project posted with the update hasn't been totally > refactored, its very confusing for those new to GAE, GWT, MVP, etc > (and it shouldn't be). This seems akin to turning in your homework > half-done or half-eaten by the dog... > > I would like to encourage Google to complete the refactoring, and in > doing so -- present the ideas in a more concise and clear manner. The > presentation seems to add confusion rather than clarity. > > I've found the following article to be extremely helpful in the > comprehension of MVP: > http://www.atomicobject.com/files/PresenterFirstAgile2006.pdf > Article suggests T(est)D(riven)D(esign) beginning with the Presenter > layer. > > The article also suggests a possible Adapter layer for use in getting/ > setting data between the Presenter and View layers (which, I quite > liked and made my own attempts at MVP much simpler and clearer). > > In my own experience, and reading other comments, seems that the > largest struggle people have is in understanding what code should live > in which layer, and how best to achieve that. I'd personally prefer > to see some additional instruction/suggestions assisting with these > issues. Also, I'd like to see the article updated to provide a better > overview of what is going to end up where (and why), and a better walk- > through of putting the proper bits into the proper places to achieve > that. > > > > Thank you everyone for sharing. > > > > > >@Chris Ramsdale, > > > >"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. " > > > >"Regarding the nested layer presenters, thanks for the feedback and > I'll look > > > >into our codebase for examples that we can share publicly. " > > > > > Chris, I was wondering if you can share any code samples, or if > > > possible ask google team > > > to write a tutorial on more complex layouts and navigation. (parent/ > > > child, composite views). > > > > > I've visited many forums, and this has been an area where many are > > > struggling. The MVP tutorial is great for introducing the concepts, > > > but > > > for real world applications with complex layout, i think more examples/ > > > resources are definitely helpful for those who want to follow best > > > practices. > > > > > almost all GWT books are written prior to 2009, mainly dealing with > > > widgets, and very little on architecture, especially MVP. > > > > > Thank You > > -- > 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.
