If you follow the second link, watch the video and you should understand, as Maryan said.
The following paragraph is almost the same words Ray Ryan spoke at the Google IO concerning MVC and MVP: "I keep saying "MVP, MVP, MVP." And I did not say MVC. Now the odds are that when you got out of the five or ten years you spent doing JSP and Web 1.0 app, you kind of dusted off some desktop knowledge or somebody who had once done that kind of work told you, "You know what we should really be doing "now that we've got these widgets is model, view, controller." And it's this kind of triangular thing. And the model throws events. And then the view throws events. And the controller messes with both of them. And I forget what code goes in the controller and what code goes into the view. And no two people will give you the same answer for what MVC actually means. There are a handful of guys who wrote Smalltalk-80, but thev may well be retired. You also wind up with a problem here that, like I said, some of your code landed in the controller. Some of it landed in the view. You need to test it all. And the code that landed in the view is not going to run real fast. It's messing with the DOM. And you either need to have a pretend DOM there If you're lucky, which we don't provide you-- yet-- or you need to fire up a real DOM. And those tests are just not going to run fast. So what you want to do instead is use the model, view, presenter pattern. We found ourselves implementing this style kind of by accident, just trying to isolate our code from tests. And then some people who are brighter than me were reading Martin Fowler's blog and saw that he had already invented this pattern before most of us were professionally active and had called it MVP. So we call it that too. Then what you're doing is just much simpler layering. Your view class down there at the bottom is the only thing that actually knows anything about DOM elements and widgets.And it's a source of things like KeyboardEvent and ClickEvent and very browser- specific events. The model at the top, we're familiar with at this point. It's this kind of overglorified bag of setters and getters that we're using because we decided we don't like property change listeners. And that leaves the presenter in the middle as the only object that has anything that's really worth testing. This is the thing that knows how to take,say, a contact in one end and take its values and cram them into a bunch of text fields on the other side, listen for changes to those text fields, and interpret them as something-- as values to push back into the model. Read carefully but i recommend to watch the video as well. On Dec 16, 11:33 pm, mariyan nenchev <[email protected]> wrote: > Watch best practices from ray ryan to understand. -- 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.
