CODEWITHSUNDEEP
javagwtmvp
user1768830
user1768830

Reputation:

GWT: AcceptsOneWidget vs Composite vs IsWidget

GWT has a lot of similarly-named (and seemingly similarly-purposed) types:

When/where is it appropriate to use each of these? What is their relationship to the RootPanel?

Upvotes: 8

Views: 1903

Answers (2)

Thomas Broyer
Thomas Broyer

Reputation: 64561

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 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 a GWT 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 TextBox and 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 (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 Widgets for low-level things (rarely needed), and Composites or IsWidgets for everything else, rather than extending existing widgets.

Upvotes: 11

Kaushik
Kaushik

Reputation: 3381

You have got all mixed up.

Widget: It allow you to interact with the users. (e.g. Button)

Panels: These are widgets that can contain other panels/widgets. Can be referred as container of widgets.

AcceptsOneWidget: Implemented by panels which will accept only one widget. (e.g SimplePanel)

Composite: A type of widget that can wrap another widget, hiding the wrapped widget's methods. The composite is useful for creating a single widget out of an aggregate of multiple other widgets contained in a single panel.

IsWidget: An interface implemented by almost all known widgets. It Provides access to that widget.

SimplePanel: A panel which contains only one widget.

RootPanel: Is the base panel to which all other panels are added.

Upvotes: 4

Related Questions