I think I can see where you´re getting at, but I´m a bit confused here
so I need to ask a couple of more questions :-)
Let´s say we return an interface as in your example, our interface
would then look something like
interface ContactDetailsInterface {
HasInternationalContactDetails getContactDetails();
}
You then have your view:
public class ContactDetailsWidget extends Composite implements
ContactDetailsInterface{
}
But where does the HasInternationalContactDetails come in?
Would your model be implementing that interface?
Something like
public class ContactDetails implements HasInternationalContactDetails
{
}
Sorry for the confusion, I´m glad you´re trying to sort things out for
us though :-)
On 20 Aug, 01:15, 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
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
