I think Jason has hit the nail on the head. The reason I got uncomfortable with the HasXxx's is that they expose the internal workings of the Viewer (Display in RR's terms). The name getSelectionButton() is a clue. The presenter doesn't and shouldn't care about how the Viewer decides how to trip an action - it might be by some convoluted means like a time out and then HasClickHandler makes no sense.
The other thing that made me uncomfortable was where Display was defined - in the Viewer implementation. As soon as I did a second implementation: a mock object, I can see that something is going wrong. As a programmer I find myself being too focused on the internal view when I should be looking at how consumers of an interface see it. Guice for example sees it's core entities as injectors but I see them as factories. As the consumer, the Presenter is the boss here and, for example, a sign in Viewer only needs (g/s)etAccountName(), getPassword () and a 'signIn' callback. The HasXxxx expose a whole lot of other functionality that you don't want anybody using. In summary 1/ Define your Presenter logic 2/ Define your Viewer interface 3/ Unit test your Presenter implementation 4/ Implement and test your Viewer --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
