The main reason (for me) for removing and dependencies on the model from the view is that as you add dependencies, you will also add state. You will then be managing your application state in your view, which is (1) something you would want to use JUnit for, and (2) a major reason for the presentation layer in the first place.
By the way, Martin Fowler does a good job of breaking down MVP... he uses three descriptions of the pattern: http://martinfowler.com/eaaDev/PassiveScreen.html (what GWT developers would typically call MVP, I think) http://martinfowler.com/eaaDev/SupervisingPresenter.html http://martinfowler.com/eaaDev/PresentationModel.html On Feb 15, 8:49 am, Yaakov Chaikin <[email protected]> wrote: > On Mon, Feb 15, 2010 at 8:20 AM, Eric <[email protected]> wrote: > > It would be great if someone would post a non-trivial example of MVP. > > I have struggled extrapolating from the Contacts App into more complex > > arrangements. I am by no means an authority, so please correct me. > > > My first take away was that their were a few rules: > > 1) Presenters don't know about specific GWT widgets (so that you can > > test your business logic without GWTTestCase) > > 2) Displays don't know about business logic > > 3) Displays don't know about application logic > > 4) Displays don't know about model classes > > > I still consider the first 3 to be sacrosanct, but I have pretty much > > dropped rule #4. I don't see a conceptual difference between a String > > and a Contact. It seems silly to write code like: > > for ( int i = 0 ; i < name.length ; i++ ) { > > if ( active[i] ) { ... do stuff... } > > if ( email[i] != null ) { ...do stuff...} > > myPanel.add( name[i] ) ; > > } > > > when I could just write: > > for ( Contact contact : contacts ) { > > if ( contact.getActive() ) { ... } > > if ( contact.getEmail() != null ) { ... } > > myPanel.add( contact.getName() ) ; > > } > > Well, I certainly undertood MVP the way Jan did... Question for you > though... My understanding is that the presentation logic should go > into the Presenter (unlike in MVC, the presentation logic goes into > the view). So, why couldn't the logic of iteration and 'if' statements > go into the presenter and the only thing would be left for the view to > do is add the name String? > > > For one thing the first way of doing it makes your code more sensitive > > to changes in your model. If I add or rename a field in my model I > > have to edit my presenter to make another parallel array instead of > > just having the new field available to display. > > Interesting point. Seems to have some validity to me. This reminds me > of the argument for DTO pattern being useless and basically an attempt > to mirror domain model objects, which, as the argument goes, doesn't > accomplish much as you'd have to change them in sync. > > > I would definitely agree that an operation like sorting should be done > > in the presenter, but then it should call > > "display.setContacts(contacts)" with the new sorted list. Similarly > > at first I had a rule that displays wouldn't attach any event > > handlers, but now I allow fairly trivial event handlers (those that > > just do a "History.addItem()"). > > Hmm... I am not sure I'd call history management a 'trivial event'. > That's a major app navigational event. Besides, as Ray explained, it's > not a good idea to sprinkle history management all over your app. A > PlaceService is a much better way of handling that. > > > I have still enforced a rule against > > the display having a handle to the event bus, but my resolve is > > wavering on that as well. > > Why? What's the use case that you are finding you'd rather handle the > events right in the view? Just curious. > > Thanks, > Yaakov. -- 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.
