Re: newbie question: what return type to use for TextBox?

[Jens]

I don't know mvp4g but what you describe is pretty normal. If you expose your widget as feature interfaces you would need to add a method per feature like:

Focusable getNameFocusable();

HasText getNameHasText();

Technically you can define more interfaces as "return value" by using generics:

<T extends Focusable & HasText> T getTextBox() {

  return (T) textbox; //unchecked cast!

}

which will allow you to access methods from both interfaces when calling view.getTextBox().someMethod() but I dont recommend it because the downsides are:

- you don't get a compile time error if textbox does not implement the interfaces T extends from because its an unchecked cast to T.

- you don't get a compile time error if you assign the return type to something different like HasEnabled enabled = view.getTextBox(). You could even write something like Person p = view.getTextBox() which is plain wrong. Also because of the unchecked cast to T.

So I tend to not use feature interfaces in my views. Instead of view.getNameTextBox().get/setText(String) I simply use view.get/setName(String). Its shorter, more meaningful and you dont have to struggle with a good name for a HasXYZ getter method (adding the widget class name or the feature interface name to the getter method name seems silly and something like view.getName().getText() also looks kind of silly to me). If I need to make the name focusable I would add view.setNameFocused(boolean). So yes, I would add a new method to the view, like you would add a new getter now.

In some cases I push the model class to the view like view.display(person) / view.getPerson(). This allows you to implement some minor logic into the view and can help to keep the presenter a bit more cleaner. Some people dont like it because the view knows about the model but I am fine with it as it can be more practical.

For events I also dont use feature interfaces (e.g. HasClickHandlers). I define my own Delegate interface that contains event callback methods, like "onNameChanged", and then call view.setDelegate(delegate). This works pretty well with UiBinder's @UiHandler and in general it saves you a lot of anonymous classes in your presenter.

So short story: Add a new method to your interface as its the safest thing to do. If you think your presenter looks a bit ugly because of lengthly view.getX().get/setY() method calls, don't use the feature interfaces in your view and instead define methods that work with the concrete values, e.g. String getName, Date getBirthday(), setAddressFocused(boolean), ... 

Hope that helps.

-- J.