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