gwt Widget AcceptsOneWidget Composite IsWidget SimplePanel

Let’s first separate interfaces from classes.

Interfaces are great for mocking (thus allowing for testing your app without the need for the sluggishGWTTestCase):

  • IsWidget: when all you need is a handle on a widget, without depending on the Widget 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 an IsWidget). 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 aGWT environment (for unit tests, that means a GWTTestCase):

  • Widget: the base of all widgets. Implements IsWidget returning itself from asWidget().
  • 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 a Composite 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 include TabPanel (built from a TabBar and DeckPanel), DateBox (built from a TextBoxand DatePicker in a PopupPanel), ValueListBox that wraps a ListBox or ValuePicker that wraps a CellList. In many cases, given that panels accept IsWidget children, you could simply implement IsWidget rather extend Composite, but it’s sometimes useful to have a true Widget.
  • SimplePanel a panel that implements AcceptsOneWidget, useful as a slot when using activities (but you could also easily implement AcceptsOneWidget 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 (IsWidgetAcceptsOneWidget) 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 Widgets for low-level things (rarely needed), and Composites or IsWidgets for everything else, rather than extending existing widgets.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s