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 <[email protected]> wrote: > > On Tue, Nov 3, 2009 at 1:21 PM, Nathan Wells > <[email protected]<https://mail.adaptivecomputing.com/zimbra?app=mail&view=compose&[email protected]>> > 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 > > <[email protected]<https://mail.adaptivecomputing.com/zimbra?app=mail&view=compose&[email protected]>> > 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 > >> <[email protected]<https://mail.adaptivecomputing.com/zimbra?app=mail&view=compose&[email protected]>> > 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 > >> > <[email protected]<https://mail.adaptivecomputing.com/zimbra?app=mail&view=compose&[email protected]> > > > >> > 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 -~----------~----~----~----~------~----~------~--~---
