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 > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
