I'm not putting everything in the presenter. For example, I do validation in the presenter and I just call a method display.showErrors(ValidationErrors errors); or display.hideErrors(). The widget has the logic to show or hide. For example, I have an external class that add an "error" class to a widget and add a hint popup with the error message. When I call showErrors, the widget just call this class and voila the widget will have the class "error" and a focus handler to show/hide the hint.
Best regards, Eduardo S. Nunes On Thu, Aug 20, 2009 at 2:11 PM, Davis Ford<[email protected]> wrote: > > 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 > > > > -- Eduardo S. Nunes http://e-nunes.com.br --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
