widget interfaces

[Stephen Haberman]

Hi,

Bringing this up again, but I'd like to submit a CL that moves the
IsButton, IsListBox, etc., interfaces I've made for Tessell into GWT
itself. IMO they would be useful to users doing MVP.

I believe the only recent objection was from Goktug, who wanted to take
the opportunity to make the widget API better, more-modern, non-sucky.

My assertion is that is a perfectly fine goal, but should be done
separately from the IsButton/etc. interfaces I'm proposing. AFAICT
there's no reason we couldn't have IsButton go in today, which matches
the old-school Button API directly, and then eventually have a next-gen
Button/whatever that has a new/better API.

Also, I would anticipate the newer/better widgets being more of a clean
break anyway, so why not let the old widgets keep their current API,
if now just codified in interfaces?

Goktug, does that sound okay? Any other concerns?

- Stephen

[Jens]

Kind of funny that I was just thinking about your old thread and Goktugs answer that he wants to try some new ways of writing widgets. Just wondering if he already came up with something :) I would definitely prefer starting from zero without IE 6-8 in mind for new widgets.

I think adding interfaces would be ok, although I am not sure if I would ever need an interface for such low level widgets like checkbox, textbox, button, etc. They are wrapped anyways in larger views which just have meaningful setters to fill them. And using UiBinder you probably also have an interface to delegate UI events to a presenter. So what would be the added benefit in terms of MVP? I don't have real concerns about adding these interface as they dont hurt but I am just curious about how useful they really are for developers that already use MVP + UiBinder + Event delegate interface.

-- J.

[Stephen Haberman]

Hi Jens,

> I would definitely prefer starting from zero without IE 6-8 in mind
> for new widgets.

With new widgets, definitely agree, I just think that's orthogonal to
adding interfaces for the existing widgets.

> So what would be the added benefit in terms of MVP?

In the Type 1 style of MVP, the view interface exposes widgets directly
to the presenter, albeit via the HasXxx characteristic interfaces. This
can get annoying if you need multiple characteristics exposed for a
single widget, or need to call a method that is not in a HasXxx
interface.

I think both of those points make the unified widget interfaces useful,
and, IMO, they're much cleaner than hacks like faking out GWT.create to
mock concrete classes like TextBox.

So, I think the interfaces are worthwhile of their own accord.

As to why I personally am extra fond of them, once you can look at a
ui.xml file and deterministically say a gwt:TextBox should be exposed
as an IsTextBox (vs. having to know did the programmer want HasValue?
HasClickHandlers?), then you can generate the view interface and
UiBinder implementation file automatically. Which is what Tessell does.

- Stephen

[Goktug Gokdogan]

Yeah, agreed; we will very likely need a cleaner plate so it is ok from my side for the IsXXX interfaces.

If nobody else has any other concerns, I recommend you to start with an example interface to get early feedback and iterate from there.

- Stephen

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Goktug Gokdogan]

The general idea is to use custom elements + html templates which can be extended for uibinder like support and/or data binding.

I have been dealing with bugs so I didn't have much progress in that last weeks; my goal is to make the idea more clear before the end of the Q2.

--

[Jens]

> I would definitely prefer starting from zero without IE 6-8 in mind
> for new widgets.

With new widgets, definitely agree, I just think that's orthogonal to
adding interfaces for the existing widgets.

Yep, agreed.

 

> So what would be the added benefit in terms of MVP?

In the Type 1 style of MVP, the view interface exposes widgets directly
to the presenter, albeit via the HasXxx characteristic interfaces. This
can get annoying if you need multiple characteristics exposed for a
single widget, or need to call a method that is not in a HasXxx
interface.

Yeah this Type 1 style is really PITA in the long term, especially if views are a bit more complex. Its not just about exposing multiple characteristics of a single widget, its also about finding good names for these methods. I always had trouble with it. IMHO getPersonName().setValue() looks strange and anything else looks even stranger. Personally, I was never really pleased with this solution.

However, with the release of UiBinder we constantly tell people/recommend to use the Type 2 style of MVP with UiBinder + @UiHandler and a delegate interface if they ask for MVP in gwt-discuss. So I think this argument looses some weight as probably no one really wants to do the type 1 way anymore and only a minority still choose it for new projects.

So my concern is that nowadays developers that use MVP just dont need these interfaces anymore that badly. But these interfaces are probably nice to have for testing small widgets that self-contain their limited logic. You can then just cancel out Composite.initWidget() by overriding it during testing and then mock all fields. No need for GWTMockUtilities.disarm() or gwtmockito then.

-- J.

[Ed]

Let me see if I understand this Type 1/2 discussion correctly:

yes, the short Has* interfaces are a bit of a pain: awkward names, mass of small interfaces, must-use of class generics if you need to more Has* interfaces.

Buttt, they make them very nice manageable through general Utils* methods..

For example: My root IsWidget interface:

----

public interface FlexWidget extends IsWidget, AsIsWidget, HasTitle, HasVisible, HasStyleName, HasEnabled, HasEnsureDebugId, HasEventManagement {}

----

And The HasStyleName look like:

----

public interface HasStyleName extends HasAddStyleName {

void setStyleName(final String style);

String getStyleName();

void removeStyleName(final String style);

}

---

In the UtilsWidget class I have all kind of methods like:

----

public static <W extends HasAddStyleName > W addStyle(final W widget, final String styleName) {

if (isNotNull(widget)) {

            widget.addStyleName(styleName);

}

return widget;

}

public static <W extends HasStyleName> W setStyle(final W widget, final String styleName) {

if (isNotNull(widget)) {

            widget.setStyleName(styleName);

}

return widget;

}

public static <W extends HasEnsureDebugId> W ensureDebugId(final W widget, final String debugId) {

if (isNotNull(widget)) {

            widget.ensureDebugId(debugId);

}

return widget;

}

----

This makes coding safe, short and easy to understand/maintain (fluent coding)...

Concerning implementation:

If you create a Is* widget like IsButton you have to think about when to create the contains Widget variant like the Button class. I want to do this as lazy as possible... 

So the question is, if you call IsButton.addStyle(String), do you forward this directly to the contained Button or do you buffer it? I buffer it, such that I can run these operations in unit tests (not GWTTestCase...

[Jens]

The general idea is to use custom elements + html templates which can be extended for uibinder like support and/or data binding.

Sounds a bit like AngularJS directives for reusable components.

[Stephen Haberman]

> If you create a Is* widget like IsButton you have to think about when
> to create the contains Widget variant like the Button class.

No, for the simple case (that I am proposing anyway), it's just:

class Button implements IsButton {
// nothing else changes
}

So no lazily creation/delegation of methods/etc. At least in the
default widgets. If you want to do that with your own wrappers, that is
fine.

> I buffer it, such that I can run these operations in unit tests (not
> GWTTestCase...

The simpler thing than buffering is just to have a StubButton, e.g.:

class StubTextBox implements IsTextBox {
private String currentValue;
// get/set/etc.
}

Then you just need a factory/something somewhere, "newButton" that in
GWT code returns real Buttons and in test code returns StubButtons.

Tessell already has stubs for most widgets; I was going to explore
moving to GWT proper as well, after/if the widget interfaces are
accepted.

- Stephen

[Goktug Gokdogan]

Yes, more accurately it is html5 web components + related specs adapted to GWT.

On Wed, Jun 5, 2013 at 2:09 PM, Jens <jens.ne...@gmail.com> wrote:

The general idea is to use custom elements + html templates which can be extended for uibinder like support and/or data binding.

Sounds a bit like AngularJS directives for reusable components.

--

[Ed]

The simpler thing than buffering is just to have a StubButton, e.g.: 

Ahhhh, how could I forget ;)... I just remember the Stubs* Widgets in your gitHub  ;)

But is this even needed ? 

If you use a template mechanism it might not be needed. 

The template is created during setStyle() and other operations and only used in GWT client mode when the underlying "Widget" is created...

[Stephen Haberman]

> Yeah this Type 1 style is really PITA in the long term, especially if
> views are a bit more complex.

I disagree; I actually prefer Type 1. Although to each their own, of
course.

> However, with the release of UiBinder we constantly tell
> people/recommend to use the Type 2 style of MVP with UiBinder +
> @UiHandler and a delegate interface if they ask for MVP in
> gwt-discuss.

UiHandler makes inner classes 2 lines shorter, but IMO it still leads
to the same spaghetti code (reactive/imperative, instead of
declarative).

Tessell's binding DSL makes simple/common operations one line
declarations (explicitly via Type 1-exposed widget interfaces, not
UiHandlers). E.g. I don't see how UiHandlers/Type 2 could be as
succinct as:

https://github.com/stephenh/todomvc-tessell/blob/master/src/main/java/org/tessell/todomvc/client/app/TodoPresenter.java#L43

> So I think this argument looses some weight as probably no one really
> wants to do the type 1 way anymore and only a minority still choose
> it for new projects.

Well, that is unfortunate, as MVP Type 1 with Tessell's view generation
and binding DSL is quite pleasant. But, again, to each their own. :-)

> No need for GWTMockUtilities.disarm() or gwtmockito then.

Exactly.

- Stephen

[Colin Alworth]

What are we looking at having in these interfaces? The discussion that Goktug and I had a few months ago got stalled around the concept that these interfaces were trying to both be a) implementation independent but also b) rich enough to be useful. Doing both is hard/meaningless.

To pick an example, button has a few basic premises (in the standard GWT widgets) - it has text (or html if you support a base other than an <input>), it can receive focus, and it is a source of click events. In a perfect world an implementation could be backed by an appearance (perhaps wrapped itself in a cell) like the TextButton...

But this ends up meaning that 'click' events aren't the only thing to worry about - a <div> won't pass along key events like space or enter as a means of activating the button. So we either need to also emit key events, and touch events, or need to wrap all of these in one event (GXT calls it a SelectEvent).

Either we have a backward compat problem (can't represent both past and future button-ish widgets with the same interface), or we limit the button implementations to a single setup (must be backed by <button> or <input>, or perhaps an <a>?).

So, my point: Is the purpose of the IsButton *only* to be an interface for com.google.gwt.user.client.ui.Button? Or are we trying to build this out for the ideal button (and ideal text box, etc)?

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
218.248.6165
nilo...@gmail.com

[Colin Alworth]

Slight follow up to both Stephen's comments here and my own prev post - If the interfaces are for existing, standard, built-in GWT widgets, type 2 makes a lot more sense, whereas for type 1, we really seem to need a general, ideal button that can be replaced by any implementation (with possibly any internal rebuilding via appearance/cells/etc).

-Colin

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
218.248.6165
nilo...@gmail.com

[Ed]

So, my point: Is the purpose of the IsButton *only* to be an interface for com.google.gwt.user.client.ui.Button? 

Good point, when submitting my prev post, I was just think about:

What problem is being solved here? Or What is improved ? 

Maybe good to summarize the list of goals and then work on them (like the white papers proposals in the gwt wiki).

Either we have a backward compat problem

I would start a separate IsWidget hierarchy. That makes it easier and overcomes all kind of conflicts and pain...

People can then to decide them self if they want to use them.. 

[Jens]

UiHandler makes inner classes 2 lines shorter, but IMO it still leads
to the same spaghetti code (reactive/imperative, instead of
declarative).

Tessell's binding DSL makes simple/common operations one line
declarations (explicitly via Type 1-exposed widget interfaces, not
UiHandlers). E.g. I don't see how UiHandlers/Type 2 could be as
succinct as:

https://github.com/stephenh/todomvc-tessell/blob/master/src/main/java/org/tessell/todomvc/client/app/TodoPresenter.java#L43

> So I think this argument looses some weight as probably no one really
> wants to do the type 1 way anymore and only a minority still choose
> it for new projects.

Well, that is unfortunate, as MVP Type 1 with Tessell's view generation
and binding DSL is quite pleasant. But, again, to each their own. :-)

Yeah but you can't really compare GWT proper to Tessell as your framework does probably generate quite some code to make all these declarative binding features possible as you always need to remember what to do once an action occurs. Also in Tessell one just leads to the other. You only have UiBinder xml and while generating the view implementation you have no idea what events the developer is interested in. So you are forced to expose all ui:field widgets/elements to allow the developer to do something with the view. Well and most common/easy things are then one liners through your binder to make life easy but complex things still require something like a command or you can't use the binder at all. So for slightly more complex things you also end up with anonymous classes.

How these things play together in Tessel is totally fine as thats Tessell! :) But in GWT proper you don't have all these stuff. Tessell should not influence your motivation to integrate something into GWT proper (don't take me wrong on this).

So if you stick to GWT proper and don't want to re-code Tessell then you probably stick to MVP Type 2. Once you do that, your view only has setter methods, gets really dump and is probably not worth testing through unit tests. In that case the Is* interfaces for GWT build-in widgets loose value. 

But, as already said, these Is* interfaces really make sense when you want to test simple composite widgets. Say you have a button and a textbox and once you click the button, the textfield should be validated and a custom event fired if everything is ok. In that case you wont do full blown MVP and having Is* interfaces for Button/TextBox available will be really handy for testing. 

So for this use case  I would go for these Is* interfaces in GWT proper as they can encourage people to not use full blown MVP for everything while still being able to write non-hacky tests.

@Colin: These interfaces are direct representations of current GWT widget classes. So its not "the ideal button interface".

-- J.

 

[Thomas Broyer]

On Wednesday, June 5, 2013 11:37:08 PM UTC+2, Colin Alworth wrote:

What are we looking at having in these interfaces? The discussion that Goktug and I had a few months ago got stalled around the concept that these interfaces were trying to both be a) implementation independent but also b) rich enough to be useful. Doing both is hard/meaningless.

To pick an example, button has a few basic premises (in the standard GWT widgets) - it has text (or html if you support a base other than an <input>), it can receive focus, and it is a source of click events. In a perfect world an implementation could be backed by an appearance (perhaps wrapped itself in a cell) like the TextButton...

But this ends up meaning that 'click' events aren't the only thing to worry about - a <div> won't pass along key events like space or enter as a means of activating the button. So we either need to also emit key events, and touch events, or need to wrap all of these in one event (GXT calls it a SelectEvent).

Either we have a backward compat problem (can't represent both past and future button-ish widgets with the same interface), or we limit the button implementations to a single setup (must be backed by <button> or <input>, or perhaps an <a>?).

So, my point: Is the purpose of the IsButton *only* to be an interface for com.google.gwt.user.client.ui.Button? Or are we trying to build this out for the ideal button (and ideal text box, etc)?

If the former, then I understand it as mostly a mean to provide mocks/stubs/fakes for testing. How about gwt-mockito then?

https://github.com/google/gwtmockito

(I'd rather go with the latter, as you described above, which would mean it's only in "widgets 2" that Daniel has been talking about on the issue tracker)

[Stephen Haberman]

> So, my point: Is the purpose of the IsButton *only* to be an
> interface for com.google.gwt.user.client.ui.Button? Or are we trying
> to build this out for the ideal button (and ideal text box, etc)?

Right, the former.

That doesn't mean the latter isn't worth doing, just that I think it's
a separate effort (because it would take awhile and having breaking
changes anyway, while I think the widgets would benefit from these
interfaces in the short-term and they are very simple to add.)

- Stephen

[Stephen Haberman]

> If the former, then I understand it as mostly a mean to provide
> mocks/stubs/fakes for testing. How about gwt-mockito then?
> https://github.com/google/gwtmockito

This is tangenting a bit...but... :-)

I know everyone uses them, but IMO mocks are less than ideal for
testing UI code. With stubs, you can have state and semi-intelligent
behavior without repeating every test the same "oh, right, this is how
a textbox works...when call this, then return that, expect so and so",
etc.

That said, mocks are a personal preference, and while nifty tools like
gwt-mockito exist for the current state of affairs, I don't think that means
making life easier for everyone (by making the require for gwt-mockito go away)
is a bad thing.

- Stephen

[Stephen Haberman]

> as your framework does probably generate quite some code to make
> all these declarative binding features possible

No, actually--the bindings don't have any code generation to them,
either build-time or gwt-compile-time. They're pure Java, which means
they run in unit tests (it would suck if they didn't...then too much
logic/behavior wouldn't be testable).

> You only have UiBinder xml and while generating the view
> implementation you have no idea what events the developer is
> interested in. So you are forced to expose all ui:field
> widgets/elements to allow the developer to do something with the
> view.

Precisely. That is a good thing, IMO. Why is that a bad thing? It means
the view is so dumb it doesn't (and *can't*) have any logic in it.
(Sorry, feel free to treat that question as rhetorical if you want to
drop the Tessell tangent. :-).

> So for slightly more complex things you also end up with anonymous classes.

Of course. But, speaking from experience, it's surprising how often
that is not true.

> Button/TextBox available will be really handy for testing.
> So for this use case I would go for these Is* interfaces in GWT
> proper as they can encourage people to not use full blown MVP for
> everything while still being able to write non-hacky tests.

Cool.

- Stephen

[Goktug Gokdogan]

On Wed, Jun 5, 2013 at 7:34 PM, Stephen Haberman <ste...@exigencecorp.com> wrote:

> If the former, then I understand it as mostly a mean to provide
> mocks/stubs/fakes for testing. How about gwt-mockito then?
> https://github.com/google/gwtmockito

This is tangenting a bit...but... :-)

I know everyone uses them, but IMO mocks are less than ideal for
testing UI code. With stubs, you can have state and semi-intelligent
behavior without repeating every test the same "oh, right, this is how
a textbox works...when call this, then return that, expect so and so",
etc.

Just for the sake of correctness;

You can still have similar stubs like you have today based on gwt-mockito (if you don't like mockito's 'expect' style).

 

That said, mocks are a personal preference, and while nifty tools like
gwt-mockito exist for the current state of affairs, I don't think that means
making life easier for everyone (by making the require for gwt-mockito go away)
is a bad thing.

- Stephen

[Stephen Haberman]

> Just for the sake of correctness;
> You can still have similar stubs like you have today based on
> gwt-mockito (if you don't like mockito's 'expect' style).

Ah, sorry, my fault for not looking in to it more. Thanks for the
correction.

- Stephen

[Daniel Kurka]

Hi Stephen,

I actually don't want to complicate the whole thing by throwing another thing into the discussion, so feel free to tell me off, but here I go:

If we construct these interfaces along the lines of todays widgets how would one add other things along them, like touch support?

Note: there is a different between a click and a touchstart, no touchmove and touchend.

In mgwt we unify those situations as a TapEvent, but I am not sure if we want to introduce something like this into GWT proper yet.

I am just a little worried that it might be very hard to fit a new widget concept under these interfaces, but maybe we can plan ahead or not bother at all.

Just wanted to bring up my concerns.

Other than that I am very much in favor of adding these to GWT proper since I found myself rewriting those a couple of times.

-Daniel

- Stephen

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

Google Germany GmbH

Dienerstr. 12
80331 München

Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Graham Law, Katherine Stephens

[Stephen Haberman]

Hi Daniel,

> I actually don't want to complicate the whole thing by throwing
> another thing into the discussion, so feel free to tell me off, but
> here I go:

No problem, what's another tangent? :-)

> If we construct these interfaces along the lines of todays widgets how
> would one add other things along them, like touch support?

I don't know anything about touch support, but the interfaces would
support touch events however you end up getting the underlying widgets
to support them.

E.g. if you need to add Panel.addTapHandler, then the IsPanel interface
would get that method too. And that's it, I think.

> Other than that I am very much in favor of adding these to GWT proper
> since I found myself rewriting those a couple of times.

Cool! I'm hopeful that more people will find them useful as well, once
they have them available.

- Stephen

[Stephen Haberman]

> If nobody else has any other concerns, I recommend you to start with
> an example interface to get early feedback and iterate from there.

So, I was going to start with just one, but copy/pasting them over and
changing the package name was pretty easy, so:

https://gwt-review.googlesource.com/#/c/3231/

I only changed a few of the widgets to implement their IsXxx
counterpart (Button, ComplexPanel, AbsolutePanel)--all pretty trivial.

I didn't realize this before, but I ended up slipping IsElement in here
because it's part of the extended IsWidget interface. There are some
other IsElement related things, like having IsElement extend HasStyle
and HasText that I'm flexible on, but are handy IMO.

Very much request for comment sort of state. Anyone feel free to
respond here or in the code review.

- Stephen

[Ed Bras]

FYI: the IsElement interfaces corresponds to issue 7497:

http://code.google.com/p/google-web-toolkit/issues/detail?id=7497

- Stephen

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
---
You received this message because you are subscribed to a topic in the Google Groups "GWT Contributors" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit-contributors/odoaoi1s7N0/unsubscribe?hl=en-US.
To unsubscribe from this group and all its topics, send an email to google-web-toolkit-co...@googlegroups.com.

[Stephen Haberman]

Hi Ed,

> FYI: the IsElement interfaces corresponds to issue 7497:
> http://code.google.com/p/google-web-toolkit/issues/detail?id=7497

Oh, right, I forgot about that...well, maybe it will go in after
all. :-)

- Stephen

[Stephen Haberman]

> I'd like to submit a CL that moves the IsButton, IsListBox, etc.

Okay, I think this CL is at a pretty good state and ready for
high-level comments:

https://gwt-review.googlesource.com/#/c/3231

I have most of the common widgets covered, but not all--e.g. the older
panels I haven't used yet, so I had not made interfaces for.

Probably the two main discussion points would be:

1) I added a new characteristic interface, HasStyle, that both
IsElement and IsWidget extend. This allows helper methods that
hide/show/etc. things via CSS to take either a widget or an element.

To me this is helpful, but it does technically introduce some new APIs
(Element.addStyleName) vs. just making interfaces for existing
methods.

I can take this out if it really rubs people the wrong way.

2) I haven't added any javadocs to the interfaces--not sure the best
approach here.

If the interfaces were included from day 1, I believe the "meaty"
javadocs would be in the interface, and the widget javadocs would just
be pointers, e.g. "See javadoc in the IsXxx#method interface".

But that would be a lot of work to move all of those over, and today
users are used to the javadocs in the widgets themselves anyway, so I
don't think we should move them.

But having absolutely no javadocs in the interfaces is probably not
good either--any suggestions? Just a token "See javadocs in the
widget"? With a specific "@link" to the widget implementation?

That may take awhile, but is something I could slog through...

- Stephen

[Stephen Haberman]

> 1) I added a new characteristic interface, HasStyle, that both
> IsElement and IsWidget extend

Sorry, IsWidget2. I didn't change IsWidget itself, of course.

I suppose that is another discussion point--in Tessell I could put the
"IsWidget with more methods than just asWidget" into a separate
org.tessell package and still call it "IsWidget".

Then I'd just be sure to import the more-featureful/Tessell version of
IsWidget in my code/tests.

But now that it the sits right along side the original/only-asWidget
IsWidget, I had to come up with some incredibly clever name, like
IsWidget2.

Suggestions are welcome.

(Perhaps make it an inner interface of IsWidget? Like IndexedPanel and
IndexedPanel.ForIsWidget; move IsWidget2 into IsWidget as
IsWidget.SomeGoodName.)

- Stephen

[Jens]

But now that it the sits right along side the original/only-asWidget
IsWidget, I had to come up with some incredibly clever name, like
IsWidget2.

What about IsWidget.Extended ?

-- J.

[Stephen Haberman]

> What about IsWidget.Extended ?

That's actually pretty good.

Maybe IsWidget.Full...eh, just thinking that is shorter, and there are a lot of places where I use the extended IsWidget type.

- Stephen

[Stephen Haberman]

> Sorry, IsWidget2. I didn't change IsWidget itself, of course.

Just mulling over options, it is too bad we won't get default methods
until Java 8, as otherwise they would be a nifty way of adding the
extra methods directly to the existing IsWidget itself, without
breaking any existing implementations.

- Stephen