i think at this point we should all probably see http://code.google.com/events/io/2010/sessions/architecting-production-gwt.html
and see what they're trying to do there. Seems like Google decided the MVP approach is obsolete, which might muddle the issue. On Thu, Jun 3, 2010 at 09:26, Thomas Broyer <t.bro...@gmail.com> wrote: > > > On 2 juin, 20:43, nogridbag <nogrid...@gmail.com> wrote: > > Mainly because of habit - I always try to avoid mixing UI related code > > with client/server code. IMHO, it seems similar to doing RPC calls in > > a controller or view in MVC which I think is a big no-no. > > > > Sticking with the article example, let's say you have two places where > > you want to display contacts. The data is the same, but the views may > > be completely different and thus you may want different presenters. > > > > So now you have: > > ContactsModel > > ContactsPresenter > > ContactsView > > > > ContactsPresenter2 > > ContactsView2 > > > > You already have the RPC call to load and initialize the ContactsModel > > in ContactsPresenter. Do you simply duplicate this in > > ContactsPresenter2 or does ContactsPresenter2 have a dependency on > > ContactsPresenter? > > > > Anyway, I'm really just thinking out loud here ;) I haven't sat down > > and coded any thing with MVP yet. If this is the accepted practice I > > will probably do it this way too. > > How about using some client-side cache, so that when your second > presenter asks for the same data as the first one, you don't send a > request on the wire (have a look at Ray Ryan's I/O 2009 talk: > > http://code.google.com/events/io/2009/sessions/GoogleWebToolkitBestPractices.html > ) > Your presenters don't have to know there's some caching involved > though, as long as the service instance is injected into the > presenter, you can pass a "right to the wire" implementation (a direct > GWT.create() on your service interface) or a "through cache" > implementation. > > If you want your views to be somehow "synchronized" (when one > presenter makes a request, the other is informed, at least when the > response comes back), then fire some events on the event bus (again, > this would be implemented in your service, not in the presenters > themselves). > > Again, MVP as used in GWT (at least as promoted by Google) has mainly > three goals: > - making unit tests possible in "pure Java" (no browser, or browser- > emulation, involved), which reduces testing time drastically! > - decoupling things a bit so you could use different views for a > single "presentation logic" (let's say a desktop view that presents > data in columns, and a mobile view that uses a taller single-column > screen) > - presenters a lightweight compared to views, so instead of > "resetting" your presenter with some new data, just throw it away, > create a new one with the new data, and "attach" it to the very same > view. > > -- > 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<google-web-toolkit%2bunsubscr...@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.
