The widget isn't aware of the model, it's just a widget for user input.
Ian

http://examples.roughian.com


2009/8/20 Dalla <[email protected]>

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

Reply via email to