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
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
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
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
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
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:
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
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
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
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
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
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..
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
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
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
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
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
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
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
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
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
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)
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
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,
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
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
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
--
27 matches
Mail list logo
