Guys, thanks for the link to this video. It really opened my eyes! I am so thankful!
2009/12/17 Joe <joechahh...@gmail.com> > 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 <nenchev.mari...@gmail.com> > 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 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. > > > -- Regards, Alexander -- 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.
