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.
