I don't see a need for more than a couple of clickhandlers (submit, cancel, maybe reset) or any blurhandlers in your main interface. What are they all for? A real-world example would help.
Ian http://examples.roughian.com 2009/8/20 Davis Ford <[email protected]> > > Hi Ian -- yep, I've already started moving most of this into model > classes, and then the display interface gets a lot simpler, like: > > interface Display { > Model getModel( ); > ... > } > > as opposed to: > > interface Display { > HasValue<String> value1(); > HasValue<String> value2(); > ... > } > > but I still have a lot of click handlers, blur handlers, etc. i don't > suppose there is any way around that aside from something dean > mentioned which is to return something like a map, but then you have > to create a structured key (like enum), and it just makes coding > against it more of a pain, i think...so i'll live with the multiple > HasHandlers interface methods. > > On Thu, Aug 20, 2009 at 10:32 AM, Ian Bambury<[email protected]> wrote: > > Hi Davis, > > I think you need to move the functionality for each text box into its own > > set of MVP classes. Everything gets a lot simpler (interfaces, coding, > > debugging, testing, maintenance etc) and once done, these classes are > > reusable. You can usually knock out a new one based on one you already > have. > > Except the first one, of course, but you might be able to nick my example > > code for that :-) > > Ian > > > > http://examples.roughian.com > > > > > > 2009/8/20 Davis Ford <[email protected]> > >> > >> 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 > >> > >> > > > > > > > > > > > > > -- > Zeno Consulting, Inc. > home: http://www.zenoconsulting.biz > blog: http://zenoconsulting.wikidot.com > p: 248.894.4922 > f: 313.884.2977 > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
