I´m still not sure I´m following :-/ Could you please post a short example?
On 20 Aug, 13:15, Ian Bambury <[email protected]> wrote: > 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 -- 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 -~----------~----~----~----~------~----~------~--~---
