The way I see it (and there is obviously a lot of room for interpretation based on app needs), you want to actually make your view (i.e. widgets) as generic as possible, while the work of "what" should be displayed is up to the presenter. For example, I created a form-like section that has an interface that defines methods like
void addField(String label, String value); HasValue<String> addEditableField(String label, String initialValue); void addFlag(String label, boolean value); HasValue<Boolean> addEditableFlag(String label, boolean initialValue); That way, any presenter can use the same interface, which can be swapped out for user experience reasons. The idea is, you want the presenter to worry about getting data to and from the view, not the intricacies of user experience. By the same token, you don't want your view worrying about anything remotely resembling your application model. I realize this isn't the only way to do it, and doing it this way requires a little bit of work getting components to fit together, but it makes your architecture much more sane, IMHO. On Aug 19, 8:14 am, davis <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
