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