Using MVP

[P.G.Taboada]

Hi,

I am running into Java compilation issues.
Example:

public class LoginPresenter {

public interface Display {

<T extends HasValue<String> & HasBlurHandlers> T getUsernameTextBox
();

HasValue<String> getPasswordTextBox();

HasValue<String> getErrorMessageBox();

HasClickHandlers getLoginButton();
}

// ...
}

While I can define a Display that returns a TextBox, I can't use the
getUsernameTextBox without doing the assignment type inference against
a concrete something implementing both interfaces in my presenter.

How do you handle this?

brgds,

Papick

[Philip Alldredge]

Hi,
That's a good question and I am curious about the proper way to handle
it. One way I came up with for handling it is this.:

class SpecializedObjectWrapper<T extends HasValue<String> &
HasBlurHandlers> extends ObjectWrapper<T>
{
public SpecializedObjectWrapper(T v)
{
super(v);
}
}

class ObjectWrapper<T>
{
public ObjectWrapper(T value)
{
this.value = value;
}

public T getValue() { return value; }
private T value;
};

Then use:
SpecializedObjectWrapper<?> getUsernameTextBox()

for your method.

This seems a bit bulky to me, although one can shared the
ObjectWrapper class and create a new SpecializedObjectWrapper for each
unique return type. I am interested if there is a more elegant
solutions.

[Brian]

One solution would be to have two different methods on the interface
such as:

HasValue<String> getUsernameField();
HasBlurHandlers getUsernameInput();

I'm not sure I like those names, but the point is that getting the
value and adding a blur handler can be different concerns from the
point of view of the presenter. From the view's perspective, it's a
nice convenience that TextBox has both or these features so it can
fulfill both methods of the interface with the same object. The view
also has the freedom to use different objects if that made sense to
do. Finally, there's the added bonus that not even the method name
implies that a TextBox is being used.

-Brian