IsTextBox/widget-specific interfaces

[Stephen Haberman]

Hi,

I've been doing GWT MVP development lately and, while the HasText,
HasValue<T>, etc. interfaces are nice and facilitate mocking/stubbing
out views, I'm wondering why GWT doesn't go further and add per-widget
interfaces.

For example, if I have a TextBox that I want to both listen for clicks
and set its value, I need 2 methods in my view interface: HasText and
HasClickHandlers. And in the view implementation, they both return the
same TextBox field.

Each time I want a new HasXxx feature of a widget, I need yet another
boilerplate method in my view interface and implementation.

Also, there are methods in widgets that are not in HasXxx interfaces,
e.g. Hyperlink.setTargetHistoryToken, and many more widget-specific
methods don't end up in HasXxx interfaces.

Instead, if there was a single IsTextBox interface, that looked like:

public interface IsTextBox extends IsTextBoxBase, HasDirection {
int getMaxLength();
int getVisibleLength();
void setMaxLength(int length);
void setVisibleLength(int length);
}

All TextBox would have to do is add "implements IsTextBox" and now the view
interfaces can return IsTextBox just once and let the presenter do any number
of things to it in a nice decoupled-via-an-interface manner.

I'd be willing to submit a patch that adds these interfaces, or at least the
ones I've needed so far. I'm doing other fancy things (specifically generating
my entire view interface, view impl, and view stub from just the ui.xml file)
that would be made easier if widgets had their own IsXxx interfaces.

Thanks,
Stephen

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Thomas Broyer]

On Apr 22, 5:55 pm, Stephen Haberman <step...@exigencecorp.com> wrote:
> Hi,
>
> I've been doing GWT MVP development lately and, while the HasText,
> HasValue<T>, etc. interfaces are nice and facilitate mocking/stubbing
> out views, I'm wondering why GWT doesn't go further and add per-widget
> interfaces.
>
> For example, if I have a TextBox that I want to both listen for clicks
> and set its value, I need 2 methods in my view interface: HasText and
> HasClickHandlers. And in the view implementation, they both return the
> same TextBox field.
>
> Each time I want a new HasXxx feature of a widget, I need yet another
> boilerplate method in my view interface and implementation.

Or you could use a "delegate", as enlightened in the GWT MVP tutorial
Part II published earlier this week: http://code.google.com/webtoolkit/articles/mvp-architecture-2.html
(the Presenter<T> interface).
I've switch to this approach a few weeks ago and it really reads
better! I can use @UiHandler and/or event delegation in views, and
mocks in unit tests are waaay easier to write (and waaay more
readable!)

[Stephen Haberman]

> Or you could use a "delegate", as enlightened in the GWT MVP tutorial
> Part II published earlier this week:http://code.google.com/webtoolkit/articles/mvp-architecture-2.html
> (the Presenter<T> interface).

Hm? I'm not seeing how a Presenter<T> interface would let my presenter
call, say, the Anchor.setTarget method.

If IsAnchor existed, I could have a "IsAnchor MyView.fooAnchor()"
method and do "display.fooAnchor().setTarget(...)" from my presenter.

The Part II article is interesting--I like its parting comment that
MVP apps are inherently a lot of boilerplate. I'm trying to avoid
that. :-)

- Stephen

[Thomas Broyer]

On Apr 23, 11:45 pm, Stephen Haberman <step...@exigencecorp.com>
wrote:

> > Or you could use a "delegate", as enlightened in the GWT MVP tutorial
> > Part II published earlier this week:http://code.google.com/webtoolkit/articles/mvp-architecture-2.html
> > (the Presenter<T> interface).
>
> Hm? I'm not seeing how a Presenter<T> interface would let my presenter
> call, say, the Anchor.setTarget method.
>
> If IsAnchor existed, I could have a "IsAnchor MyView.fooAnchor()"
> method and do "display.fooAnchor().setTarget(...)" from my presenter.

You wouldn't have a MyView.fooAnchor() getter but a
MyView.setFooAnchorTarget(String) setter.

[Stephen Haberman]

> You wouldn't have a MyView.fooAnchor() getter but a
> MyView.setFooAnchorTarget(String) setter.

Yes, I understand that is how you're supposed to do things now. I'm
saying its annoying to re-type so much boilerplate presenter <->
widget abstraction code into every view in an app.

With IsXxx interfaces on widgets, the abstraction is inherent and
presenters can directly manipulate IsXxx widgets even while in junit
tests. UiBinder-driven views become so boilerplate (because all they
have to do is expose each @UiField as its corresponding IsXxx
interface) that I can generate the entire thing.

- Stephen