[New subject line for the new subject. ]
Sorry, no samples to point you at right now. And no, @UiHandler will
only work in the class that owns the binder, the view.
I've seen different teams approach communication between view and
presenter in different ways. Some will give the view interface methods
like "HasValue<String> nameField()", which wouldn't benefit from
@UiHandler at all. Others put the View in the business of translating
UI events into semantic events (and give the View a back pointer to
the presenter), e.g.:
@UiHandler("updateButton")
void onBoldClicked(ClickEvent e) {
owner.updateRequested();
}
rjrjr
On Tue, Nov 3, 2009 at 1:45 PM, Nathan Wells <nwwe...@gmail.com> wrote:
> Let me be clear: I'm not currently using the UIBinder for my development.
> Let me know if this is a catastrophic mistake, but we started this project
> before UIBinder was available, so we went with MVP. It could be (and
> hopefully is) the case that my concerns with disappear when I start using
> UIBinder more.
>
> In the mean time, am I to understand that your @UiHandler annotations should
> be in your presenter classes? Some samples I've looked at haven't worked
> this way. Is there a UIBinder example that does this?
>
> Nathan Wells
>
>
> On Tue, Nov 3, 2009 at 2:31 PM, Ray Ryan <rj...@google.com> wrote:
>>
>> On Tue, Nov 3, 2009 at 1:21 PM, Nathan Wells <nwwe...@gmail.com> wrote:
>> >
>> > @Scott
>> > Thanks for the insight into the discussions. Maybe this will be
>> > something possible to add in the future, in some form.
>> >
>> > @Bruce
>> > I like what I see with the UIBinder methodology... However, there is
>> > some amount of incompatibility with the MVP approach, unless I'm
>> > mistaken. This is because all Composite classes require GwtTestCases,
>> > whereas a presenter-layer Handler class would be JUnit testable. Have
>> > there already been thoughts about integrating the concepts of MVP and
>> > UIBinder? What searching I've done hasn't turned up much.
>>
>> UiBinder doesn't require composite. Anyway, we pretty much backed into
>> use of the MVP pattern because of our use of UiBinder's predecessor.
>> You build your View with UiBinder, and your Presenter doesn't know a
>> thing about it. What's the actual issue you're running into?
>> >
>> > I would love to see a discussion about combining MVP and UIBinder
>> > (though that's probably a topic for a different thread).
>> >
>> > On Nov 3, 11:36 am, Matt Mastracci <matt...@mastracci.com> wrote:
>> >> I think the impact of anonymous classes will be significantly less
>> >> once union types are implemented. As it stands right now, every
>> >> anonymous class gets typeinfo and getClass because some code elsewhere
>> >> is calling it on an variable that can't be tightened more than Object.
>> >>
>> >> On 2009-11-03, at 10:23 AM, Scott Blum <sco...@google.com> wrote:
>> >>
>> >> > Hi Nathan,
>> >>
>> >> > We've talked about doing something like this, under various names,
>> >> > including "inner class elision". It seems worthwhile in the
>> >> > abstract, to reduce client-side object counts. What I'm not sure of
>> >> > is how hard it really would be to get right. In the past we've had
>> >> > discussions about the attributes of the classes to be merged.
>> >> > They'd need to be singletons within their containing class, final,
>> >> > initialized up front.. and references wouldn't be allowed to
>> >> > "escape" into the wild. And that last one is the real sticking
>> >> > point for what you want... allowing references to escape gets very
>> >> > problematic, but not allowing them to escape makes it very hard to
>> >> > actually get it to kick in for the exact case you're trying to solve.
>> >>
>> >> > Scott
>> >>
>> >> > On Tue, Nov 3, 2009 at 11:43 AM, Nathan Wells <nwwe...@gmail.com>
>> >> > wrote:
>> >>
>> >> > As I was developing this morning, I came across a trade-off that I
>> >> > wasn't happy with. Namely, as I create handlers and other interface
>> >> > implementations in a given class, the implementations create new
>> >> > classes, which adds additional, unnecessary code into the compiled
>> >> > output.
>> >>
>> >> > One way around this is to sacrifice my code readability and simply
>> >> > have the containing class implement those interfaces. For example,
>> >>
>> >> > class Foo {
>> >> > static class BarHandler implements ClickHandler, KeyDownHandler {
>> >> > ...
>> >> > }
>> >>
>> >> > static class FooCommand implements Command {
>> >> > ...
>> >> > }
>> >>
>> >> > ... class body that doesn't implement and onClick, onKeyDown or
>> >> > execute method...
>> >>
>> >> > }
>> >>
>> >> > could compile to something like
>> >>
>> >> > class Foo implements ClickHandler, KeyDownHandler, Command {
>> >> > ... merged implementations ...
>> >> > }
>> >>
>> >> > Of course, I'm operating under a few assumptions (based on my
>> >> > watching
>> >> > this group and the developer group, and my lack of knowledge about
>> >> > how
>> >> > the compiler actually works ;)
>> >>
>> >> > 1. This isn't already done,
>> >> > 2. Adding more classes actually significantly increases the bulk of
>> >> > compiled output.
>> >> > 3. The amount of time to add this optimization would be less than the
>> >> > pain of the trade-off I'm dealing with.
>> >>
>> >> > Let me know what you think,
>> >> > Nathan
>> > >
>> >
>>
>>
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
http://groups.google.com/group/Google-Web-Toolkit-Contributors
-~----------~----~----~----~------~----~------~--~---
