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. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
