> UiHandler makes inner classes 2 lines shorter, but IMO it still leads > to the same spaghetti code (reactive/imperative, instead of > declarative). > > Tessell's binding DSL makes simple/common operations one line > declarations (explicitly via Type 1-exposed widget interfaces, not > UiHandlers). E.g. I don't see how UiHandlers/Type 2 could be as > succinct as: > > > https://github.com/stephenh/todomvc-tessell/blob/master/src/main/java/org/tessell/todomvc/client/app/TodoPresenter.java#L43 > > > > So I think this argument looses some weight as probably no one really > > wants to do the type 1 way anymore and only a minority still choose > > it for new projects. > > Well, that is unfortunate, as MVP Type 1 with Tessell's view generation > and binding DSL is quite pleasant. But, again, to each their own. :-) >
Yeah but you can't really compare GWT proper to Tessell as your framework does probably generate quite some code to make all these declarative binding features possible as you always need to remember what to do once an action occurs. Also in Tessell one just leads to the other. You only have UiBinder xml and while generating the view implementation you have no idea what events the developer is interested in. So you are forced to expose all ui:field widgets/elements to allow the developer to do something with the view. Well and most *common/easy* things are then one liners through your binder to make life easy but complex things still require something like a command or you can't use the binder at all. So for slightly more complex things you also end up with anonymous classes. How these things play together in Tessel is totally fine as thats Tessell! :) But in GWT proper you don't have all these stuff. Tessell should not influence your motivation to integrate something into GWT proper (don't take me wrong on this). So if you stick to GWT proper and don't want to re-code Tessell then you probably stick to MVP Type 2. Once you do that, your view only has setter methods, gets really dump and is probably not worth testing through unit tests. In that case the Is* interfaces for GWT build-in widgets loose value. But, as already said, these Is* interfaces really make sense when you want to test simple composite widgets. Say you have a button and a textbox and once you click the button, the textfield should be validated and a custom event fired if everything is ok. In that case you wont do full blown MVP and having Is* interfaces for Button/TextBox available will be really handy for testing. So for this use case I would go for these Is* interfaces in GWT proper as they can encourage people to not use full blown MVP for everything while still being able to write non-hacky tests. @Colin: These interfaces are direct representations of current GWT widget classes. So its not "the ideal button interface". -- J. -- http://groups.google.com/group/Google-Web-Toolkit-Contributors --- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
