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.
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/google-web-toolkit/-/gSuWnKbKhcQJ.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
