gwt uibinder in an abstract parent class

[JC Tierney]

i'm wondering if there's a way to build the gwt uibinder logic into an
abstract parent class so that i don't have to repeat the code in every
class i want to bind.

for example, i'd like to be able to do something like this:

public abstract class BasePanel<Panel extends BasePanel> extends
Composite {
interface Binder<BinderPanel extends BasePanel> extends
UiBinder<Widget, BinderPanel> { }
private static final Binder binder =
GWT.create(Binder<Panel>.class);

public BasePanel() {
initWidget(binder.createAndBindUi(this));
init();
}
}

basically this would allow any child classes to do something like
this:

public MyPanel extends BasePanel<MyPanel> {
//my code here
}

the default constructor would take care of all the code to bind
MyPanel to MyPanel.ui.xml.

basically i want to be lazy and only have to build the interface and
the binder once so that it's done in a common way. thoughts?

thanks in advance.

[Ashton Thomas]

I do something very similar for a very important/complex part of my app. Not out of laziness but just because it's a goo way to keep things DRY. I use an abstract parent class which actually binds the UiBinder and then has some abstract methods that are different for subclasses.

I'm not sure how you are using the generic Panel ext MyPanel in the example above. you could probably leave that out

[Ed]

Realize that you are making yourself lazy at the cost of not-lazy code.

That is: all will be constructed in the constructor.

Try to make a difference between screen and not-screen components/classes. 

Screen components contain the GWT stuff containing the heavy stuff and should be created as late as possible, that is: only when they appear on the screen.

For one component the above will be ok, but it's hard to tell how you will use it in the near future.

Even do you you might create the above lazily and only when needed, I would still never put an initWidget() method in my constructor: the constructor should be light weight (general sun rule), and you make the code unit-testable if you don't put this method in the constructor.

I use my own SimpleComposite base class that extends from Composite that will automatically create the widget subclass when needed -> real lazy loading (I think the  SimpleComposite class appears in the issue tracker).

- Ed

[Hilco Wijbenga]

On 8 December 2011 02:18, Ed <post2...@gmail.com> wrote:
> Even do you you might create the above lazily and only when needed, I would
> still never put an initWidget() method in my constructor: the constructor
> should be light weight (general sun rule), and you make the code
> unit-testable if you don't put this method in the constructor.
> I use my own SimpleComposite base class that extends from Composite that
> will automatically create the widget subclass when needed -> real lazy
> loading (I think the  SimpleComposite class appears in the issue tracker).

It would be great if I didn't have to put initWidget() in the
constructor (so that, like you say, unit tests become much easier) but
how would that work then? I suppose you have some sort of init()
method? How does that get called then?

Moreover, in Composite it says "All composites must call initWidget()
in their constructors.". You have encountered no difficulties not
having initWidget() in the constructor?

[Ed Bras]

> Moreover, in Composite it says "All composites must call initWidget() in their constructors."

Yes, and you should if you extend directly from Composite, because Composite doesn't contain any lazy loading behavior.

But the SimpleComposite contains lazy loading behavior and will automatically ask your subclass to create the widget when required.

I have attached the SimpleComposite class, just extends from it and implement the create method..

I use it for years with success in several large gwt projects.

   
To go one step further and make your widget better testable (my other remark above), I use a SimpleIsWidget class that extends from GWT IsWidget interface and can be created outside GWT (instead of classes that extend from Widget like Composite). I contains all the widget presentation logic that can be tested.

For details, see this post:

http://groups.google.com/group/google-web-toolkit/browse_thread/thread/87030a9ae66fe012/

I you take testing in to account right from the beginning and setup your widget testing-friendly, it will cost you a lot of work afterwards when testing becomes more important (my experience)...

- Ed