What if you broke out each form field into its own view, presenter and interface all of which extend basic abstracts? Your main interface would look like
FirstNameInput getFirstName(); SurnameInput getSurname(); EmailInput getEmail(); and so on You could then do things like FirstNameInput firstName = view.getFirstName(); firstName.setRequired(true); if(firstname.isValid())... FirstNameInput would worry about validation on blur, FirstNameInputView would pass the abstract input presenter the help text. The abstract input presenter would have the code to deal with showing the help text. The abstract input view would deal with putting the help symbol on the screen. The abstract input presenter would hook up to the click event of that symbol. I know it sounds like a lot of work, but it's all reusable stuff and it's really only organising what you are already doing in a different way. Ian http://examples.roughian.com 2009/8/20 Davis Ford <[email protected]> > > 7 form fields and i do client side validation so 7 blurhandlers. > > 1 click handler for submit button. > > I also have a help image icon next to each field that the user can > click and get popup help. so that is 7 additional click handlers. > although i'm starting to think this is just stupid to put in the > presenter, as it has little more logic than adding a click handler > that does something like this: > > display.getFooHelp().addClickHandler(new ClickHandler() { > public void onClick(ClickEvent evt) { > display.showHelp(event, messages.fooHelp()); > }}); > > There isn't really a lot to validate there in a JUnit test other than > the correct messages.whatever() was sent to display.showHelp(). > > Anyway, that is 15 interface methods + 1 for the getModel() = 16. > > On Thu, Aug 20, 2009 at 12:51 PM, Ian Bambury<[email protected]> wrote: > > 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 > >> > >> > > > > > > > > > > > > > -- > 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 -~----------~----~----~----~------~----~------~--~---
