On Apr 12, 2:35 pm, Brian Reilly <[email protected]> wrote: > There is one convenience that this appears to leave out, though: > @UiHandler. These are things that MVP tells us should be in the > presenter, yet the annotation has to live in the view class instead. I > haven't fully worked out my thoughts on this yet, but having already > done MVP without UiBinder, I don't feel burdened by not using > @UiHandler. Some have talked about having the presenter register > callbacks with the view that the view can then call from @UiHandler > annotated methods, which seems cumbersome to me. Others have talked > about letting the view hold a reference to the presenter to call > specific methods (maybe defined in a presenter interface) from > @UiHandler methods. This may not be a bad approach, but I haven't > tried it myself yet.
I have a form that includes two date widgets and a "Save" button. One date represents a start date and the other represents an end date. I therefore have a business requirement that the end date not precede the start date. I would have been willing to use two @UiHandler annotations in the view class to disable 'illegal' dates on each DatePicker because that's a matter purely internal to the panel. It turned out that I could not use @UiHandler for that because there are two methods in DatePicker that take a single ShowRangeEvent argument. At least, I couldn't do that. On the other hand, the save button has its event handler attached within the presenter class. The view should not know how it is used. Respectfully, Eric Jablow -- 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.
