Hello there, IMHO, one of the issues of MVP and Gwt is the lack of good examples showing how to use all the layers (including command pattern, injection and event bus), how to test all the code, and how to integrate the set of libraries available.
Taking the project Hupa as reference, I have re-factored the Contacts project in order to integrate gwt-presenter, gwt-dispatch, gin and guice; I have coded JRE tests covering all the presenters, and GWT tests to demonstrate how to make functional tests able to check the view and rpcs; finally I have put everything in a project handled with maven and eclipse. You can download the project and play with it: svn checkout http://gwt-workshop.googlecode.com/svn/trunk/GwtWsMvpContacts GwtWsMvpContacts mvn clean test gwt:run package Hope it helps to you Cheers -Manolo On Wed, Apr 28, 2010 at 7:25 PM, Fabio Kaminski <fabiokamin...@gmail.com> wrote: > 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 <ahhug...@gmail.com> 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 <m...@sheridan-net.us> 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 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. >>> >> >> -- >> 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. > > -- > 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. > -- 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.
