Its funny when a solution creates more problems than solve issues they promissed to address..
this look to me like a politician, telling you they will solve the world hunger.. and in the and you are paying more tributes to make his cows fat.. i have go back to the whiteboard, and come back to javascript.. since at least.. gwt purposes steel better than all those rails-clone frameworks.. too bad its working on plaster java.. :s On Wed, Apr 28, 2010 at 11:41 AM, Andrew Hughes <[email protected]> wrote: > 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]<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.
