On Wednesday, April 27, 2011 1:32:47 PM UTC+2, ernesto.reig wrote:
>
> But Thomas, there´s something I don´t understand, when you say "Activities
> however are in no way related to MVP". Activities are the Presenters in the
> MVP pattern, I mean, they own the views and there happens the logic
> decoupling. The views talk/notify the Activities when some user action that
> needs logic happens. Activities are responsible to talk to the server, send
> and retrieve data, goto() other Place´s, and therefore keeping the views
> "dumb". So, when you say that Activities are not related to MVP I can only
> think that I´m missing something...
> Could you please shed a bit of light on this? :)
>
That's generally how you'll do it, but nothing in the Activity contract
enforces it. Need a proof? Here it is in 15 LOCs:
public class ActivityWithoutMvp extends AbstractActivity {
@Override
public void start(AcceptsOneWidget panel, EventBus eventBus) {
FlowPanel container = new FlowPanel();
final TextBox textBox = new TextBox();
container.add(textBox);
container.add(new Button("Say hello!", new ClickHandler() {
@Override
public void onClick(ClickEvent event) {
Window.alert("Hello " + textBox.getText() + "!");
}
}));
panel.setWidget(container);
}
}
You could also extend, say, Composite while implementing the Activity
interface. That'd work too.
It'd be in most case a brad practice as it violates the "separation of
concerns" pattern, but for very simple activities (such as the above) I
think it's OK not to use MVP.
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
