I think maybe Ian had other ideas than what I suggested above. Implementering the HasInternationalContactDetails on the ContactDetails model, and then returning it from the ContactDetailsInterface would somehow make the widget aware of the model... Which I think would break the MVP pattern...?
On 20 Aug, 07:17, "Dean S. Jones" <[email protected]> wrote: > 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- Dölj citerad text - > > - Visa citerad text - --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
