This is where I diverged from the typical MVP pattern, the Has* interfaces just became to numerous and unwieldy. My solution was to make the "model" richer, and attach a Map of "state values" to each model property. It was then up to the Presenter to interpret the associated property state map, and display accordingly.
At first, I had general "model change listeners" drive the UI. I wanted to convert to GWT 1.6+ custom events and event handlers(bus), but these grew too numerous also.... still looking for a concise solution. On Aug 19, 8:49 pm, Davis Ford <[email protected]> wrote: > You and others have won me over, Ian :) > > I re-factored to all interfaces. One of my biggest pain points was > the crazy number of mock and mock returns I was ending up needing -- > that, and I needed to included gwt-dev on the classpath, which the > codehaus gwt-maven-plugin warns not to do... > > It still blows up kind of big when you have a form with even a > reasonable number of widgets on it. Example, I have 7 text boxes on > one form. For each, I want to get at its value and also set a blur > handler...so I end up with: > > interface Display { > HasValue<String> foo(); > HasBlurHandlers fooBlur(); > ... > > } > > That leads to 14 methods in the interface -- I wish there was some way > to collapse this. I also have 7-8 additional HasClickHandlers, and a > number of methods like: > > void displayFooError(boolean toggle, String msg); > > To tell the view to report an error. So in the end, the interface for > *this* particular presenter is fairly large, but so be it, I guess. > > Sorry, to hear your project got hi-jacked. I enjoy your blog posts -- > hope you will keep posting stuff on GWT. > > Regards, > Davis > > > > > > On Wed, Aug 19, 2009 at 7:15 PM, Ian Bambury<[email protected]> wrote: > > My feeling is that, if you design things properly, you will not need to end > > up with a bloated interface. > > For example, in a registration page, you don't need to have something for > > every field if you require name/address/phone number, you just link in to > > HasInternationalContactDetails and that widget deals with all the associated > > problems. You just set it up with hicd.emailRequired(true) and > > hicd.phoneRequired(false) and so on. That widget then knows how to set > > itself up. If you need to insert current details, you use > > hicd.displayDetails(userContactDetails). > > You check everything is OK with if(!hicd.isValid())hicd.displayErrors(); > > You get the user contact details back with hicd.getContactDetails(); > > All you need in your interface is HasInternationalContactDetails > > getContactDetails(); > > Everything else works from that interface, not yours. > > Whatever it is that conforms to that knows all about zip and postal codes > > and what to validation apply (because it probably has a country dropdown and > > can use that) same with phone formats. > > The HasInternationalContactDetails widget itself uses other widgets (like > > phone number) which can be used elsewhere if needed but at the very minimum > > break the functionality into manageable units. > > I'd love to give this a try, but unfortunately my current project manager > > (and funder rolled into one) seems to have just dropped GWT in favour of > > Zend and the 'here's an idea for a screenshot, make it work' approach to > > system design. > > Sigh! > > Ian > > >http://examples.roughian.com > > > 2009/8/19 davis <[email protected]> > > >> Point taken Ian. I think the design tradeoffs are at least on the > >> table. In most cases, I think I'm comfortable with coupling the view<- > >> >presenter in a 1:1 relationship -- (i.e. not making universally > >> generic presenters that can be used with any view), but I understand > >> your argument, and can see the need for this in some scenarios. > > >> On Aug 19, 8:30 am, Ian Bambury <[email protected]> wrote: > >> > 2009/8/19 Davis Ford <[email protected]> > > >> > > My basic question is: why not just return TextBox if that is what is > >> > > in your view? The coupling is between 2 classes: view and presenter. > >> > > If you later change TextBox to SuperWidgetTextBox, you can re-factor > >> > > it in your IDE in 5 seconds and be done with it. > > >> > > Am I missing something? > > >> > If that is the way you want to go then fine. > > >> > What you might be missing is that some of your views may not be using > >> > text > >> > boxes. One view may be using a text box. Another might use a label, > >> > another > >> > might use a button, or a text area, or a hyperlink, or a menu item. They > >> > can > >> > all display text. > > >> > An on/off indicator and a switch are just a boolean and something > >> > clickable, > >> > but you don't decide in the presenter that is should be the words 'on' > >> > and > >> > 'off' and demand a label, you leave it as boolean and let the view > >> > decide > >> > whether to put yes/no, on/off, true/false, a checkbox, an image of a > >> > lightbulb on and off, etc - and the clickable thing could be a button > >> > with > >> > those words, or a picture of a switch, or the checkbox. > > >> > The presenter can be used for all these views. Different views can > >> > register > >> > with the same presenter. Users can choose their preferred view and swap > >> > views in and out. > > >> > Ian > > >> >http://examples.roughian.com > > -- > Zeno Consulting, Inc. > home:http://www.zenoconsulting.biz > blog:http://zenoconsulting.wikidot.com > p: 248.894.4922 > f: 313.884.2977 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
