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