John Ahlroos has posted comments on this change.
Change subject: Use JSON.parse() instead of eval() to deserialize rpc
callback payload
..
Patch Set 5:
(3 comments)
File
> Does having the flag really make it that much more complicated?
It would not seem like it, but yes. :-)
Specifically passing the context down through the layers to the right
spot to say "do I serialize final fields?" took a bit--one of the first
patches that went by used a static field to avoi
> 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-T
On Wed, Jun 5, 2013 at 10:46 PM, Stephen Haberman
wrote:
>
> > I don't have a good idea about what could break
>
> I believe nothing would "break"--it's that final fields that were
> previously not going over the wire would now go over the wire.
>
> So, I guess technically that is a change in sema
On Wed, Jun 5, 2013 at 7:34 PM, Stephen Haberman
wrote:
>
> > 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 t
> I don't have a good idea about what could break
I believe nothing would "break"--it's that final fields that were
previously not going over the wire would now go over the wire.
So, I guess technically that is a change in semantics--so it wouldn't
be like "oh, your GWT app fails to compile", mo
> 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 th
> 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 stub
I don't have a good idea about what could break, but who knows what we'll
find. I think we will at least want a flag to turn it on and off. It might
be temporary just to land the patch; not sure if it should survive until
the 2.6 release.
On Wed, Jun 5, 2013 at 9:03 AM, Stephen Haberman
wrote:
> 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 se
I haven't look at the code, but I think it runs a precompile, and then
stops. So it constructs the whole program AST and runs generators, so it
runs all checking up to that point. I'm pretty sure it should be running
JSORestrictionsChecker which runs on JDT I believe.
On Wed, Jun 5, 2013 at 6:2
Hi,
Anyone knowns what the -validateOnly flag to the compiler does exactly? can
it be reliably used to validate that all classes in a given module are *
translatable*?
I used it once but it was years ago so I don't remember what it checked
exactly. AFAICT it didn't check that JSNI was valid Java
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
Andrey Korzhevskiy has posted comments on this change.
Change subject: Support standardized DOM WheelEvent
https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel
..
Patch Set 2:
Ok
--
To view, visit https://gw
Thomas Broyer has posted comments on this change.
Change subject: Support standardized DOM WheelEvent
https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel
..
Patch Set 2:
They'll likely to continue supporting
Andrey Korzhevskiy has posted comments on this change.
Change subject: Support standardized DOM WheelEvent
https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel
..
Patch Set 2:
I agree but what about future ve
Hello Leeroy Jenkins,
I'd like you to reexamine a change. Please visit
https://gwt-review.googlesource.com/3250
to look at the new patch set (#2).
Change subject: Fixes UiHandler method matching in generic classes
..
Fix
Thomas Broyer has posted comments on this change.
Change subject: Support standardized DOM WheelEvent
https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel
..
Patch Set 2:
(1 comment)
Shouldn't we fix our DOM
Andrey Korzhevskiy has posted comments on this change.
Change subject: Support standardized DOM WheelEvent
https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel
..
Patch Set 2:
(1 comment)
...
Andrey Korzhevskiy has posted comments on this change.
Change subject: Support standardized DOM WheelEvent
https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel
..
Patch Set 2:
I mean, I cannot get mouse wheel
Goktug Gokdogan has uploaded a new change for review.
https://gwt-review.googlesource.com/3250
Change subject: Fixes UiHandler method matching in generic classes
..
Fixes UiHandler method matching in generic classes
Method
Thomas Broyer has posted comments on this change.
Change subject: Support standardized DOM WheelEvent
https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel
..
Patch Set 2:
(1 comment)
Andrey Korzhevskiy has posted comments on this change.
Change subject: Support standardized DOM WheelEvent
https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel
..
Patch Set 2:
(1 comment)
...
Thomas Broyer has posted comments on this change.
Change subject: Support standardized DOM WheelEvent
https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel
..
Patch Set 2:
Does it mean your Firefox no longer f
Thomas Broyer has posted comments on this change.
Change subject: Change DOM access in HTMLTable for IE
..
Patch Set 2:
(2 comments)
Should we rather move that to c.g.g.dom (Table*Element have .rows
and .cells) and rewrite
Andrey Korzhevskiy has posted comments on this change.
Change subject: Support standardized DOM WheelEvent
https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel
..
Patch Set 2:
Yes, it's Firefox. For now, gwt
Thomas Broyer has posted comments on this change.
Change subject: Support standardized DOM WheelEvent
https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel
..
Patch Set 2:
(1 comment)
Is there any browser sup
> 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
> UiHan
Thomas Broyer has posted comments on this change.
Change subject: adding compare for several number types -Byte.compare
-Short.compare -Integer.compare -Long.compare -Float.compare (Double
already exists) fixes issue 7998
...
>
> 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 w
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
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 exampl
> 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 U
>
> 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
Yes, more accurately it is html5 web components + related specs adapted to
GWT.
On Wed, Jun 5, 2013 at 2:09 PM, Jens 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
> 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/delegatio
> 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 messa
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..
F
Andrey Korzhevskiy has uploaded a new patch set (#2).
Change subject: Support standardized DOM WheelEvent
https://developer.mozilla.org/en-US/docs/Web/Reference/Events/wheel
..
Support standardized DOM WheelEvent
https://deve
Hello Leeroy Jenkins,
I'd like you to reexamine a change. Please visit
https://gwt-review.googlesource.com/3212
to look at the new patch set (#2).
Change subject: Change DOM access in HTMLTable for IE
..
Change DOM acces
Andrey Korzhevskiy has uploaded a new change for review.
https://gwt-review.googlesource.com/3171
Change subject: Support standardized DOM WheelEvent
..
Support standardized DOM WheelEvent
Fixes issue 8012
Change-Id: Ia6e8
> > 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?
>
>
Brian Slesinsky has posted comments on this change.
Change subject: Use JSON.parse() instead of eval() to deserialize rpc
callback payload
..
Patch Set 5:
(3 comments)
I like where this is going. As I understand it, all cl
Daniel Kurka has uploaded a new change for review.
https://gwt-review.googlesource.com/3212
Change subject: Change DOM access in HTMLTable for IE
..
Change DOM access in HTMLTable for IE
using table.rows or table.rows[i].ce
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 a
Yeah, agreed; we will very likely need a cleaner plate so it is ok from my
side for the IsXXX interfaces.
If nobody else has any other concerns, I recommend you to start with an
example interface to get early feedback and iterate from there.
On Wed, Jun 5, 2013 at 8:57 AM, Stephen Haberman
wrote:
Ray Cromwell has posted comments on this change.
Change subject: Emulate java.util.Objects
..
Patch Set 8: Code-Review+2
--
To view, visit https://gwt-review.googlesource.com/3184
To unsubscribe, visit https://gwt-review.googl
John A. Tamplin has posted comments on this change.
Change subject: Emulate java.util.Objects
..
Patch Set 8: Code-Review+1
--
To view, visit https://gwt-review.googlesource.com/3184
To unsubscribe, visit https://gwt-review.go
Goktug Gokdogan has posted comments on this change.
Change subject: adding compare for several number types -Byte.compare
-Short.compare -Integer.compare -Long.compare -Float.compare (Double
already exists) fixes issue 7998
.
Hello John A. Tamplin,
I'd like you to reexamine a change. Please visit
https://gwt-review.googlesource.com/3184
to look at the new patch set (#8).
Change subject: Emulate java.util.Objects
..
Emulate java.util.Objects
John A. Tamplin has posted comments on this change.
Change subject: adding compare for several number types -Byte.compare
-Short.compare -Integer.compare -Long.compare -Float.compare (Double
already exists) fixes issue 7998
.
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, t
Manuel Carrasco Moñino has posted comments on this change.
Change subject: Make Element.hasTagName(...) case-insensitive.
..
Patch Set 6: Code-Review+1
--
To view, visit https://gwt-review.googlesource.com/2975
To unsubscribe,
Manuel Carrasco Moñino has posted comments on this change.
Change subject: Fixes a NPE in RF when returning a null entity while the
client used .with().
..
Patch Set 1: Code-Review+1
LGTM
--
To view, visit https://gwt-revi
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 inter
Hey,
So, there is a CL out there that I have kinda/sorta been shepherding
along to add support to GWT-RPC for final fields.
The current CL is kinda complicated right now, because we have at least
two flags about whether to turn final-fields on/off and also whether to
warn about it when it is off.
Hi,
Bringing this up again, but I'd like to submit a CL that moves the
IsButton, IsListBox, etc., interfaces I've made for Tessell into GWT
itself. IMO they would be useful to users doing MVP.
I believe the only recent objection was from Goktug, who wanted to take
the opportunity to make the widg
Thomas Broyer has posted comments on this change.
Change subject: Make Element.hasTagName(...) case-insensitive.
..
Patch Set 6: Code-Review+2
Grrr, Jenkins really doesn't want to pick it up to give its Verified+1.
--
To view
Yep I have a similar setup in eclipse: remove trailing spaces when saving.
On Tue, Jun 4, 2013 at 10:09 PM, Goktug Gokdogan wrote:
> In Eclipse, I use auto-format on save for "edited lines".
> If it is a javadoc, it forces you to use correct javadoc tags however for
> regular multiine comments
Hello Manuel Carrasco Moñino, Daniel Kurka, Goktug Gokdogan,
I'd like you to reexamine a rebased change. Please visit
https://gwt-review.googlesource.com/2975
to look at the new rebased patch set (#6).
Change subject: Make Element.hasTagName(...) case-insensitive.
Daniel Kurka has posted comments on this change.
Change subject: Make Element.hasTagName(...) case-insensitive.
..
Patch Set 5: Code-Review+2
LGTM
You can submit this change now using the publish & submit button
--
To view,
Thomas Broyer has posted comments on this change.
Change subject: Make Element.hasTagName(...) case-insensitive.
..
Patch Set 5: Code-Review+2
--
To view, visit https://gwt-review.googlesource.com/2975
To unsubscribe, visit ht
Manuel Carrasco Moñino has posted comments on this change.
Change subject: Make Element.hasTagName(...) case-insensitive.
..
Patch Set 5: Code-Review+1
--
To view, visit https://gwt-review.googlesource.com/2975
To unsubscribe,
Daniel Kurka has posted comments on this change.
Change subject: Make Element.hasTagName(...) case-insensitive.
..
Patch Set 4: Code-Review+1
LGTM, please address Manuel's comment
--
To view, visit https://gwt-review.googleso
Manuel Carrasco Moñino has posted comments on this change.
Change subject: Make Element.hasTagName(...) case-insensitive.
..
Patch Set 4: Code-Review+1
(1 comment)
File use
John Ahlroos has posted comments on this change.
Change subject: Use JSON.parse() instead of eval() to deserialize rpc
callback payload
..
Patch Set 5:
Okay, so patch set 5 takes a much simpler approach and does not change
Hello Leeroy Jenkins, Thomas Broyer,
I'd like you to reexamine a change. Please visit
https://gwt-review.googlesource.com/2900
to look at the new patch set (#5).
Change subject: Use JSON.parse() instead of eval() to deserialize rpc
callback payload
.
Manuel Carrasco Moñino has uploaded a new patch set (#2).
Change subject: FileUpload: extending FocusWidget instead of Widget so as
it exposes many features which already are in the file-input element:
click(), focus(), mouseevents, keyevents, etc.
...
Manuel Carrasco Moñino has uploaded a new change for review.
https://gwt-review.googlesource.com/3211
Change subject: FileUpload: extending FocusWidget instead of Widget so as
it exposes many features which already are in the file-input element:
click(), focus(), mouseevents, keyevents, e
Manuel Carrasco Moñino has posted comments on this change.
Change subject: Fixes JRawType#getImplementedMethods to return correct
signature for inherited methods
..
Patch Set 1: Code-Review+1
LGTM
--
To view, visit https:/
70 matches
Mail list logo
