This is something I'm really interested in as well Stephen.
-----
How do you test these things? How does the next guy know
whether his event handler belongs in the view or the controller?
-----
If the event doesn't change the view state, it doesn't belong in the
view. I would argue that clicking a save button doesn't change the
view, so it shouldn't be added to the view, but clicking on the header
of a disclosure panel does change the view state, so it belongs in the
view.
As far as how you test them, by coding in the presenter specifically
against interfaces, you can use stubs to run your tests, still getting
all the JUnit testable goodness,
Don't forget, that by mapping each widget to an interface would allow
you to bind those up with GIN and create providers for those inside
the presenter, so if for some reasons you wanted to be able to alter
the view, you could easily do it and still keep the presenter/activity
JUnit clean.
A first awesome step to this would be to make every widget implement
an interface exposing all their public methods. I really hated
extending every control and it will become more and more of a
nightmare to maintain as the gwt codebase changes.
I'd like to look more at the ui:binder changes. My idea was to add an
annotation/annoatation processor to automatically codegen a new
interface of every public method. For example
@GenerateDisplayInterface
class SomeView implements SomeViewDisplay{
@UiField
TextBox box;
@UiField
Label label;
public SomeView(){.....}
public IsTextBox getBox(){
return box;
}
@DoNotGenerate
public IsLabel getLabel(){
return label
}
}
would generate
public interface SomeViewDisplay {
IsTextBox getBox();
}
This would then avoid the problems inhernate with having the view be
completely code genned and would allow me to put view state change
handlers inside the view.
I would LOVE LOVE LOVE for every gwt object that extends UIObject to
implement a specific interface and would be more than happy to
implement this.
On Oct 19, 1:35 pm, Stephen Haberman <[email protected]>
wrote:
> > I agree that we need a more general low-labor way to bind events in a
> > GWT app, but this doesn't seem to be it. Am I missing something?
>
> It's not necessarily related to events, but I've been pleased with the
> low-labor aspect of generating views:
>
> http://gwtmpv.org/viewgeneration.html
>
> My workflow:
>
> * In Foo.ui.xml, add a "ui:field=name" line
> * Eclipse project builder sees the change, automatically runs codegen
> * IsFooView is updated with "IsTextBox name()"
> * GwtFooView is updating with @UiField name/etc.
> * StubFooView is updated with "StubTextBox name()"
> * In FooPresenter, which extends Presenter<IsFooView>, add:
> * view.name().addClickHandler(...)
>
> Given GwtFooView is entirely generated, I cannot use @UiHandler events,
> hence FooPresenter calling "addClickHandler".
>
> However, I don't find this to be a big deal, as I'm trending towards a
> gwt-pectin-style binding DSL:
>
> // in FooPresenter onBind
> binder.bind(model.nameProperty).to(view.nameTextBox)
>
> So still no inner-classes, and the model/view keep each other up to date
> when one or the other changes. Note that the model part is entirely
> optional, it's only required if you want the handy "binder.bind" syntax.
>
> - Stephen
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
