doing MVP is to pass the presenter to the view. This isn't how MVP is
done with the other MVP frameworks(mvp4g, gwtp), and even if the new
Activity mechanism is the go forward strategy for GWT proper, I would
really like to see is something to fix all the boilerplate if you're
trying to pass your view to the Activity.
I have a presenter a view and an interface which that view implements,
lets call it a display.
Now lets say I need to add a click handler, focus handler, enable,
disable and change the text of the one particular button. In my
interface and view I have to expose 5 different methods.
HasText getButtonText();
HasClickHandlers getButtonHasClickHandlers();
HasAllFocusHandlers getButtonHasAllFocusHandlers();
void setButtonEnabled(boolean isEnabled);
boolean isButtonEnabled();
then in my view
public HasText getButtonText(){
return button;
}
public HasClickHandlers getButtonHasCLickHandlers(){
return button;
}
public HasAllFocusHandlers getButtonFocusHandlers(){
return button;
}
public void setButtonEnabled(boolean enable){
button.setEnabled(enable);
}
public void isButtonEnabled(){
return button;
}
This sucks. It is verbose, long and destroys productivity as every
time some requirement gets changed or added I have to now go make more
methods in the display. You can imagine how this would explode into
some really long and unweildy interfaces for complex forms where each
field can be enabled/disabled based upon business logic.
Obviously this is smaller and more concise.
display
IsButton getButton();
view
public IsButton getButton(){
return button;
}
where IsButton is an interface that exposes all the public methods
available on Button. Now as requirements change I already have access
to every method I would if I was doing development inside the view
itself.
This is for one button on one form. It would be so much easier if
Button implemented an interface IButton and then instead of having to
write 5 methods on button then write all the boiler plate. Maybe the
answer isn't having IsWidget expose all public methods on Widget, but
perhaps another interface, call it IWidget or WidgetInterface, then
each UI component would follow the same convention. If it would stand
a reasonable chance of being accepted, I would be happy to code a
patch for this aswell.
For my current project, I've already extended the entire GWT widget
heirarchy to do exactly this. I'm already seeing big gains in my
productivity, but I would prefer to have these changes integrated into
GWT proper as I think that would make GWT a lot easier to use.
On Oct 1, 5:36 am, Thomas Broyer <t.bro...@gmail.com> wrote:
> On Sep 30, 4:23 pm, Jeff Larsen <larse...@gmail.com> wrote:
>
> > What is the reason for IsWidget only returning the widget and not
> > having all of the public methods available to widget?
>
> The IsWidget is only there so you can mock the view without any
> dependency on Widget. In your unit tests you can then check whether
> the IsWidget is null or is the object you're expecting, but you don't
> really care what it does (this is left to the view interfaces, which
> will likely extend IsWidget).
>
> The typical ussage is:
>
> interface MyView extends IsWidget {
> interface Delegate {
> onFoo();
> }
>
> void setDelegate(Delegate delegate);
>
> }
>
> class MyActivity implements Activity, MyView.Delegate {
> @Inject MyView view;
>
> public void start(AcceptsOneWidget panel, EventBus eventBus) {
> view.setDelegate(this);
> doAsyncStartup(new WhateverCallback() {
> public void onSuccess() {
> if (view == null) {
> // we've been cancelled!
> return;
> }
> ...
> panel.setWidget(view);
> }
> });
> }
>
> public void onCancel() {
> view.setDelegate(null);
> view = null; // serves as a flag to know if we're still active
> }
>
> public void onStop() {
> // same as in onCancel, possibly more
> }
>
> public String mayStop() { ... }
>
> }
>
> With doAsyncStartup generally being a GWT-RPC, RequestFactory or
> RequestBuilder call, and WhateverCallback the appropriate callback
> interface (AsyncCallback, Receiver or RequestCallback)
>
> (if you annotate the View interface with @ImplementedBy, you don't
> even need to explicitly configure anything in GIN)
--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
No comments:
Post a Comment