[gwt-contrib] Re: widget interfaces
I'd like to submit a CL that moves the IsButton, IsListBox, etc. Okay, I think this CL is at a pretty good state and ready for high-level comments: https://gwt-review.googlesource.com/#/c/3231 I have most of the common widgets covered, but not all--e.g. the older panels I haven't used yet, so I had not made interfaces for. Probably the two main discussion points would be: 1) I added a new characteristic interface, HasStyle, that both IsElement and IsWidget extend. This allows helper methods that hide/show/etc. things via CSS to take either a widget or an element. To me this is helpful, but it does technically introduce some new APIs (Element.addStyleName) vs. just making interfaces for existing methods. I can take this out if it really rubs people the wrong way. 2) I haven't added any javadocs to the interfaces--not sure the best approach here. If the interfaces were included from day 1, I believe the meaty javadocs would be in the interface, and the widget javadocs would just be pointers, e.g. See javadoc in the IsXxx#method interface. But that would be a lot of work to move all of those over, and today users are used to the javadocs in the widgets themselves anyway, so I don't think we should move them. But having absolutely no javadocs in the interfaces is probably not good either--any suggestions? Just a token See javadocs in the widget? With a specific @link to the widget implementation? That may take awhile, but is something I could slog through... - Stephen -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: widget interfaces
1) I added a new characteristic interface, HasStyle, that both IsElement and IsWidget extend Sorry, IsWidget2. I didn't change IsWidget itself, of course. I suppose that is another discussion point--in Tessell I could put the IsWidget with more methods than just asWidget into a separate org.tessell package and still call it IsWidget. Then I'd just be sure to import the more-featureful/Tessell version of IsWidget in my code/tests. But now that it the sits right along side the original/only-asWidget IsWidget, I had to come up with some incredibly clever name, like IsWidget2. Suggestions are welcome. (Perhaps make it an inner interface of IsWidget? Like IndexedPanel and IndexedPanel.ForIsWidget; move IsWidget2 into IsWidget as IsWidget.SomeGoodName.) - Stephen -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: widget interfaces
But now that it the sits right along side the original/only-asWidget IsWidget, I had to come up with some incredibly clever name, like IsWidget2. What about IsWidget.Extended ? -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
What about IsWidget.Extended ? That's actually pretty good. Maybe IsWidget.Full...eh, just thinking that is shorter, and there are a lot of places where I use the extended IsWidget type. - Stephen -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: widget interfaces
Sorry, IsWidget2. I didn't change IsWidget itself, of course. Just mulling over options, it is too bad we won't get default methods until Java 8, as otherwise they would be a nifty way of adding the extra methods directly to the existing IsWidget itself, without breaking any existing implementations. - Stephen -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
Hi Stephen, I actually don't want to complicate the whole thing by throwing another thing into the discussion, so feel free to tell me off, but here I go: If we construct these interfaces along the lines of todays widgets how would one add other things along them, like touch support? Note: there is a different between a click and a touchstart, no touchmove and touchend. In mgwt we unify those situations as a TapEvent, but I am not sure if we want to introduce something like this into GWT proper yet. I am just a little worried that it might be very hard to fit a new widget concept under these interfaces, but maybe we can plan ahead or not bother at all. Just wanted to bring up my concerns. Other than that I am very much in favor of adding these to GWT proper since I found myself rewriting those a couple of times. -Daniel On Thu, Jun 6, 2013 at 7:32 AM, Stephen Haberman step...@exigencecorp.comwrote: Just for the sake of correctness; You can still have similar stubs like you have today based on gwt-mockito (if you don't like mockito's 'expect' style). Ah, sorry, my fault for not looking in to it more. Thanks for the correction. - Stephen -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- Google Germany GmbH *Dienerstr. 12* *80331 München* Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Katherine Stephens -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
Hi Daniel, I actually don't want to complicate the whole thing by throwing another thing into the discussion, so feel free to tell me off, but here I go: No problem, what's another tangent? :-) If we construct these interfaces along the lines of todays widgets how would one add other things along them, like touch support? I don't know anything about touch support, but the interfaces would support touch events however you end up getting the underlying widgets to support them. E.g. if you need to add Panel.addTapHandler, then the IsPanel interface would get that method too. And that's it, I think. Other than that I am very much in favor of adding these to GWT proper since I found myself rewriting those a couple of times. Cool! I'm hopeful that more people will find them useful as well, once they have them available. - Stephen -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[gwt-contrib] Re: widget interfaces
Kind of funny that I was just thinking about your old thread and Goktugs answer that he wants to try some new ways of writing widgets. Just wondering if he already came up with something :) I would definitely prefer starting from zero without IE 6-8 in mind for new widgets. I think adding interfaces would be ok, although I am not sure if I would ever need an interface for such low level widgets like checkbox, textbox, button, etc. They are wrapped anyways in larger views which just have meaningful setters to fill them. And using UiBinder you probably also have an interface to delegate UI events to a presenter. So what would be the added benefit in terms of MVP? I don't have real concerns about adding these interface as they dont hurt but I am just curious about how useful they really are for developers that already use MVP + UiBinder + Event delegate 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
Hi Jens, I would definitely prefer starting from zero without IE 6-8 in mind for new widgets. With new widgets, definitely agree, I just think that's orthogonal to adding interfaces for the existing widgets. So what would be the added benefit in terms of MVP? In the Type 1 style of MVP, the view interface exposes widgets directly to the presenter, albeit via the HasXxx characteristic interfaces. This can get annoying if you need multiple characteristics exposed for a single widget, or need to call a method that is not in a HasXxx interface. I think both of those points make the unified widget interfaces useful, and, IMO, they're much cleaner than hacks like faking out GWT.create to mock concrete classes like TextBox. So, I think the interfaces are worthwhile of their own accord. As to why I personally am extra fond of them, once you can look at a ui.xml file and deterministically say a gwt:TextBox should be exposed as an IsTextBox (vs. having to know did the programmer want HasValue? HasClickHandlers?), then you can generate the view interface and UiBinder implementation file automatically. Which is what Tessell does. - Stephen -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
The general idea is to use custom elements + html templates which can be extended for uibinder like support and/or data binding. I have been dealing with bugs so I didn't have much progress in that last weeks; my goal is to make the idea more clear before the end of the Q2. On Wed, Jun 5, 2013 at 9:39 AM, Jens jens.nehlme...@gmail.com wrote: Kind of funny that I was just thinking about your old thread and Goktugs answer that he wants to try some new ways of writing widgets. Just wondering if he already came up with something :) I would definitely prefer starting from zero without IE 6-8 in mind for new widgets. I think adding interfaces would be ok, although I am not sure if I would ever need an interface for such low level widgets like checkbox, textbox, button, etc. They are wrapped anyways in larger views which just have meaningful setters to fill them. And using UiBinder you probably also have an interface to delegate UI events to a presenter. So what would be the added benefit in terms of MVP? I don't have real concerns about adding these interface as they dont hurt but I am just curious about how useful they really are for developers that already use MVP + UiBinder + Event delegate 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
I would definitely prefer starting from zero without IE 6-8 in mind for new widgets. With new widgets, definitely agree, I just think that's orthogonal to adding interfaces for the existing widgets. Yep, agreed. So what would be the added benefit in terms of MVP? In the Type 1 style of MVP, the view interface exposes widgets directly to the presenter, albeit via the HasXxx characteristic interfaces. This can get annoying if you need multiple characteristics exposed for a single widget, or need to call a method that is not in a HasXxx interface. Yeah this Type 1 style is really PITA in the long term, especially if views are a bit more complex. Its not just about exposing multiple characteristics of a single widget, its also about finding good names for these methods. I always had trouble with it. IMHO getPersonName().setValue() looks strange and anything else looks even stranger. Personally, I was never really pleased with this solution. However, with the release of UiBinder we constantly tell people/recommend to use the Type 2 style of MVP with UiBinder + @UiHandler and a delegate interface if they ask for MVP in gwt-discuss. 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. So my concern is that nowadays developers that use MVP just dont need these interfaces anymore that badly. But these interfaces are probably nice to have for testing small widgets that self-contain their limited logic. You can then just cancel out Composite.initWidget() by overriding it during testing and then mock all fields. No need for GWTMockUtilities.disarm() or gwtmockito then. -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
Let me see if I understand this Type 1/2 discussion correctly:
yes, the short Has* interfaces are a bit of a pain: awkward names, mass of
small interfaces, must-use of class generics if you need to more Has*
interfaces.
Buttt, they make them very nice manageable through general Utils* methods..
For example: My root IsWidget interface:
public interface FlexWidget extends IsWidget, AsIsWidget, HasTitle,
HasVisible, HasStyleName, HasEnabled, HasEnsureDebugId, HasEventManagement
{}
And The HasStyleName look like:
public interface HasStyleName extends HasAddStyleName {
void setStyleName(final String style);
String getStyleName();
void removeStyleName(final String style);
}
---
In the UtilsWidget class I have all kind of methods like:
public static W extends HasAddStyleName W addStyle(final W widget, final
String styleName) {
if (isNotNull(widget)) {
widget.addStyleName(styleName);
}
return widget;
}
public static W extends HasStyleName W setStyle(final W widget, final
String styleName) {
if (isNotNull(widget)) {
widget.setStyleName(styleName);
}
return widget;
}
public static W extends HasEnsureDebugId W ensureDebugId(final W widget,
final String debugId) {
if (isNotNull(widget)) {
widget.ensureDebugId(debugId);
}
return widget;
}
This makes coding safe, short and easy to understand/maintain (fluent
coding)...
Concerning implementation:
If you create a Is* widget like IsButton you have to think about when to
create the contains Widget variant like the Button class. I want to do this
as lazy as possible...
So the question is, if you call IsButton.addStyle(String), do you forward
this directly to the contained Button or do you buffer it? I buffer it,
such that I can run these operations in unit tests (not GWTTestCase...
--
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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
The general idea is to use custom elements + html templates which can be extended for uibinder like support and/or data binding. Sounds a bit like AngularJS directives for reusable components. -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
If you create a Is* widget like IsButton you have to think about when
to create the contains Widget variant like the Button class.
No, for the simple case (that I am proposing anyway), it's just:
class Button implements IsButton {
// nothing else changes
}
So no lazily creation/delegation of methods/etc. At least in the
default widgets. If you want to do that with your own wrappers, that is
fine.
I buffer it, such that I can run these operations in unit tests (not
GWTTestCase...
The simpler thing than buffering is just to have a StubButton, e.g.:
class StubTextBox implements IsTextBox {
private String currentValue;
// get/set/etc.
}
Then you just need a factory/something somewhere, newButton that in
GWT code returns real Buttons and in test code returns StubButtons.
Tessell already has stubs for most widgets; I was going to explore
moving to GWT proper as well, after/if the widget interfaces are
accepted.
- Stephen
--
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 google-web-toolkit-contributors+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
Yes, more accurately it is html5 web components + related specs adapted to GWT. On Wed, Jun 5, 2013 at 2:09 PM, Jens jens.nehlme...@gmail.com wrote: The general idea is to use custom elements + html templates which can be extended for uibinder like support and/or data binding. Sounds a bit like AngularJS directives for reusable components. -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
The simpler thing than buffering is just to have a StubButton, e.g.: A, how could I forget ;)... I just remember the Stubs* Widgets in your gitHub ;) But is this even needed ? If you use a template mechanism it might not be needed. The template is created during setStyle() and other operations and only used in GWT client mode when the underlying Widget is created... -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
Yeah this Type 1 style is really PITA in the long term, especially if views are a bit more complex. I disagree; I actually prefer Type 1. Although to each their own, of course. However, with the release of UiBinder we constantly tell people/recommend to use the Type 2 style of MVP with UiBinder + @UiHandler and a delegate interface if they ask for MVP in gwt-discuss. 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. :-) No need for GWTMockUtilities.disarm() or gwtmockito then. Exactly. - Stephen -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
What are we looking at having in these interfaces? The discussion that Goktug and I had a few months ago got stalled around the concept that these interfaces were trying to both be a) implementation independent but also b) rich enough to be useful. Doing both is hard/meaningless. To pick an example, button has a few basic premises (in the standard GWT widgets) - it has text (or html if you support a base other than an input), it can receive focus, and it is a source of click events. In a perfect world an implementation could be backed by an appearance (perhaps wrapped itself in a cell) like the TextButton... But this ends up meaning that 'click' events aren't the only thing to worry about - a div won't pass along key events like space or enter as a means of activating the button. So we either need to also emit key events, and touch events, or need to wrap all of these in one event (GXT calls it a SelectEvent). Either we have a backward compat problem (can't represent both past and future button-ish widgets with the same interface), or we limit the button implementations to a single setup (must be backed by button or input, or perhaps an a?). So, my point: Is the purpose of the IsButton *only* to be an interface for com.google.gwt.user.client.ui.Button? Or are we trying to build this out for the ideal button (and ideal text box, etc)? On Wed, Jun 5, 2013 at 4:28 PM, Ed post2edb...@gmail.com wrote: The simpler thing than buffering is just to have a StubButton, e.g.: A, how could I forget ;)... I just remember the Stubs* Widgets in your gitHub ;) But is this even needed ? If you use a template mechanism it might not be needed. The template is created during setStyle() and other operations and only used in GWT client mode when the underlying Widget is created... -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 218.248.6165 niloc...@gmail.com -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
Slight follow up to both Stephen's comments here and my own prev post - If the interfaces are for existing, standard, built-in GWT widgets, type 2 makes a lot more sense, whereas for type 1, we really seem to need a general, ideal button that can be replaced by any implementation (with possibly any internal rebuilding via appearance/cells/etc). -Colin On Wed, Jun 5, 2013 at 4:36 PM, Stephen Haberman step...@exigencecorp.comwrote: Yeah this Type 1 style is really PITA in the long term, especially if views are a bit more complex. I disagree; I actually prefer Type 1. Although to each their own, of course. However, with the release of UiBinder we constantly tell people/recommend to use the Type 2 style of MVP with UiBinder + @UiHandler and a delegate interface if they ask for MVP in gwt-discuss. 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. :-) No need for GWTMockUtilities.disarm() or gwtmockito then. Exactly. - Stephen -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 218.248.6165 niloc...@gmail.com -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
So, my point: Is the purpose of the IsButton *only* to be an interface for com.google.gwt.user.client.ui.Button? Good point, when submitting my prev post, I was just think about: What problem is being solved here? Or What is improved ? Maybe good to summarize the list of goals and then work on them (like the white papers proposals in the gwt wiki). Either we have a backward compat problem I would start a separate IsWidget hierarchy. That makes it easier and overcomes all kind of conflicts and pain... People can then to decide them self if they want to use them.. -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
On Wednesday, June 5, 2013 11:37:08 PM UTC+2, Colin Alworth wrote: What are we looking at having in these interfaces? The discussion that Goktug and I had a few months ago got stalled around the concept that these interfaces were trying to both be a) implementation independent but also b) rich enough to be useful. Doing both is hard/meaningless. To pick an example, button has a few basic premises (in the standard GWT widgets) - it has text (or html if you support a base other than an input), it can receive focus, and it is a source of click events. In a perfect world an implementation could be backed by an appearance (perhaps wrapped itself in a cell) like the TextButton... But this ends up meaning that 'click' events aren't the only thing to worry about - a div won't pass along key events like space or enter as a means of activating the button. So we either need to also emit key events, and touch events, or need to wrap all of these in one event (GXT calls it a SelectEvent). Either we have a backward compat problem (can't represent both past and future button-ish widgets with the same interface), or we limit the button implementations to a single setup (must be backed by button or input, or perhaps an a?). So, my point: Is the purpose of the IsButton *only* to be an interface for com.google.gwt.user.client.ui.Button? Or are we trying to build this out for the ideal button (and ideal text box, etc)? If the former, then I understand it as mostly a mean to provide mocks/stubs/fakes for testing. How about gwt-mockito then? https://github.com/google/gwtmockito (I'd rather go with the latter, as you described above, which would mean it's only in widgets 2 that Daniel has been talking about on the issue tracker) -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
So, my point: Is the purpose of the IsButton *only* to be an interface for com.google.gwt.user.client.ui.Button? Or are we trying to build this out for the ideal button (and ideal text box, etc)? Right, the former. That doesn't mean the latter isn't worth doing, just that I think it's a separate effort (because it would take awhile and having breaking changes anyway, while I think the widgets would benefit from these interfaces in the short-term and they are very simple to add.) - Stephen -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
If the former, then I understand it as mostly a mean to provide mocks/stubs/fakes for testing. How about gwt-mockito then? https://github.com/google/gwtmockito This is tangenting a bit...but... :-) I know everyone uses them, but IMO mocks are less than ideal for testing UI code. With stubs, you can have state and semi-intelligent behavior without repeating every test the same oh, right, this is how a textbox works...when call this, then return that, expect so and so, etc. That said, mocks are a personal preference, and while nifty tools like gwt-mockito exist for the current state of affairs, I don't think that means making life easier for everyone (by making the require for gwt-mockito go away) is a bad thing. - Stephen -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
as your framework does probably generate quite some code to make all these declarative binding features possible No, actually--the bindings don't have any code generation to them, either build-time or gwt-compile-time. They're pure Java, which means they run in unit tests (it would suck if they didn't...then too much logic/behavior wouldn't be testable). 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. Precisely. That is a good thing, IMO. Why is that a bad thing? It means the view is so dumb it doesn't (and *can't*) have any logic in it. (Sorry, feel free to treat that question as rhetorical if you want to drop the Tessell tangent. :-). So for slightly more complex things you also end up with anonymous classes. Of course. But, speaking from experience, it's surprising how often that is not true. 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. Cool. - Stephen -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
On Wed, Jun 5, 2013 at 7:34 PM, Stephen Haberman step...@exigencecorp.comwrote: If the former, then I understand it as mostly a mean to provide mocks/stubs/fakes for testing. How about gwt-mockito then? https://github.com/google/gwtmockito This is tangenting a bit...but... :-) I know everyone uses them, but IMO mocks are less than ideal for testing UI code. With stubs, you can have state and semi-intelligent behavior without repeating every test the same oh, right, this is how a textbox works...when call this, then return that, expect so and so, etc. Just for the sake of correctness; You can still have similar stubs like you have today based on gwt-mockito (if you don't like mockito's 'expect' style). That said, mocks are a personal preference, and while nifty tools like gwt-mockito exist for the current state of affairs, I don't think that means making life easier for everyone (by making the require for gwt-mockito go away) is a bad thing. - Stephen -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [gwt-contrib] Re: widget interfaces
Just for the sake of correctness; You can still have similar stubs like you have today based on gwt-mockito (if you don't like mockito's 'expect' style). Ah, sorry, my fault for not looking in to it more. Thanks for the correction. - Stephen -- 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 google-web-toolkit-contributors+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
