Let's first separate interfaces from classes.
Interfaces are great for mocking (thus allowing for testing your app without the need for the sluggish GWTTestCase
):
IsWidget
: when all you need is a handle on a widget, without depending on theWidget
class. This is typically used with MVP as a way to represent the view.AcceptsOneWidget
: when you need a placeholder for a single widget (in the form of anIsWidget
). This is typically used with Activities, to insert the view (IsWidget
) into the given slot (AcceptsOneWidget
).
The classes you list all extend Widget
, so they rely on JSNI and (most of the time) need to run in a GWT environment (for unit tests, that means a GWTTestCase
):
Widget
: the base of all widgets. ImplementsIsWidget
returning itself fromasWidget()
.Composite
: a base class when you need to create a widget built from other widgets while hiding their implementation. While you could extend an existing widget, it's generally better to hide it inside aComposite
so you only expose the API you need/want to expose.Composite
is about "composition rather than inheritance" and encapsulation. Examples of composites in standard widgets includeTabPanel
(built from aTabBar
andDeckPanel
),DateBox
(built from aTextBox
andDatePicker
in aPopupPanel
),ValueListBox
that wraps aListBox
orValuePicker
that wraps aCellList
. In many cases, given that panels acceptIsWidget
children, you could simply implementIsWidget
rather extendComposite
, but it's sometimes useful to have a trueWidget
.SimplePanel
a panel that implementsAcceptsOneWidget
, useful as a slot when using activities (but you could also easily implementAcceptsOneWidget
to insert into any kind of panel)
That being said, Google recently open-sourced GWT-Mockito that plugs Mockito into GWT.create()
and uses classloader magic to rewrite JSNI methods and remove final
modifiers so you can directly use widgets in tests without the need for GWTTestCase
or MVP.
So, all in all, it depends how you approach your code, how you architecture your app. If you use MVP, stick to depending on interfaces only (IsWidget
, AcceptsOneWidget
) in your presenter so you can easily mock your view in your tests.
Otherwise, or if you want a "simplified MVP" where the view is a UiBinder template, try GWT-Mockito for your tests and directly use widgets.
Of course, you can mix both approaches in the same application. And in any case, build your own widgets as Widget
s for low-level things (rarely needed), and Composite
s or IsWidget
s for everything else, rather than extending existing widgets.