[gwt-contrib] Change in gwt[master]: FileUpload: extending FocusWidget instead of Widget so as it...
Manuel Carrasco Moñino has posted comments on this change.
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.
..
Patch Set 5:
(1 comment)
File user/src/com/google/gwt/user/client/ui/FileUpload.java
Line 209: public void click() {
click() is the name we use in other widgets (inputs, button, submit), so I
think we should use the same to be coherent.
I think developers know that click does a different thing in different
elements, and the expected behavior in file-input is open the file dialog.
--
To view, visit https://gwt-review.googlesource.com/3211
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I4bc3c0991c5025a10a14b2f04ece6d91e11bcddb
Gerrit-PatchSet: 5
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Manuel Carrasco Moñino
Gerrit-Reviewer: Daniel Kurka
Gerrit-Reviewer: Leeroy Jenkins
Gerrit-Reviewer: Manuel Carrasco Moñino
Gerrit-Reviewer: Matthew Dempsky
Gerrit-Reviewer: Patrick Tucker
Gerrit-Reviewer: Thomas Broyer
Gerrit-HasComments: Yes
--
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] Working on a patch to fix Exception wrapping/unwrapping in compiler
I just wanted to give you a heads up that Roberto and I are working on a compiler patch so that catch statement will not break js originated exceptions. To give you some background, if you put any try/catch statement in Java, js originated exceptions will be converted into JavaScriptException even if you are not catching a JavaScriptException or any of its parents. Because of this problem there are workarounds in SDK to avoid catch statements if there are no UncaughtExceptionHandlers registered. By avoiding "catch" statements and repeating code, we are making sure a js exception can correctly escape and reported by the browser. Also with this patch, we can make some exceptions escape to the browser asynchronously without breaking the code flow. This is useful to fix problems like issue #6833 and similar others in the SDK. -- 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] Work to do for bug 3042
Agreed. We don't need to provide a complex RichTextArea for GWT out of the box. It makes sense to quickly iterate on it in a different open source project. In the meantime, if you end up having small patches to improve the existing one in GWT, feel free to send them. On Fri, Jun 14, 2013 at 3:34 PM, Brian Slesinsky wrote: > Another possibility would be to develop a nicer GWT RichTextArea as a > separate open source project. There's no reason it has to be in core GWT > right away and you'll be able to work faster that way. With real-world > usage, you'll probably learn a few things that will make it better quality > if we do merge it back to core later. > > However, if you have to patch GWT to make it work, that is the sort of > thing that should be contributed back to GWT. > > On Thu, Jun 13, 2013 at 10:03 PM, Manuel Carrasco Moñino < > man...@apache.org> wrote: > >> In my opinion, having the tool-bar in gwt makes perfectly sense, >> RichTextArea is almost unusable without a bar in any project. It's >> plenty of gwt projects which have copied and pasted the code from the >> showcase. >> >> I think that you should face this issue in some steps: >> 1.- Listen to GWT contributors for the convenience of moving >> RichTextToolbar from samples to gwt. So maintain live this thread >> until you get enough feedback. >> 2.- Send a first patch just moving the code from show-case to gwt >> (showcase should use the new code) >> 3.- When the patch were accepted, continue adding other features like >> adding/removing widgets from the toolbar, or a panel grouping >> RichTextArea + RichTextToolbar, etc. because each thing needs a >> different review/discussion. >> >> - Manolo >> >> On Tue, Jun 11, 2013 at 7:25 PM, Adolfo Panizo Touzon >> wrote: >> > Oh! Sorry I saw you were the owner and I thought you had plenty of >> > responsability. >> > >> > Thanks, but everything is fine, the installation process is quite >> > simple/clear, so, all is up and running. :D. >> > >> > Keep an eye into the Issue 1127 because maybe you are interested in >> giving >> > instructions related to both issues. >> > >> > Thanks, >> > >> > Adolfo. >> > >> > >> > On Tue, Jun 11, 2013 at 10:28 AM, Daniel Kurka >> wrote: >> >> >> >> Hi Adolfo, >> >> >> >> this is not my issue and I am not solely responsible for it. >> >> >> >> We should see wait and see if anybody opposes to adding this to GWT, >> >> before you actually start working on it, so that your time will not be >> >> wasted. >> >> On the other hand you can already setup your IDE and tools to be able >> to >> >> start. James pointed out the resources. If there is anything wrong / >> unclear >> >> in those resources please let us know. Or you could even send a patch >> for >> >> the homepage to be updated. >> >> >> >> - Daniel >> >> >> >> >> >> On Mon, Jun 10, 2013 at 8:07 PM, Adolfo Panizo Touzon >> >> wrote: >> >>> >> >>> Thanks James! >> >>> >> >>> But I have done those steps yet (indeed I read in that link I should >> ask >> >>> here first :D) . When I said the necessary work I meant the steps for >> >>> develop the RichTextArea according to the GWT steering committee (for >> this >> >>> issue I think Daniel is responsible) so I need to wait for his >> opinion. >> >>> >> >>> Thanks anyway for your quick response. >> >>> >> >>> Adolfo. >> >>> >> >>> >> >>> On Mon, Jun 10, 2013 at 1:02 PM, James Horsley < >> james.hors...@gmail.com> >> >>> wrote: >> >> Adolfo, >> >> To get the source checked out and compiling follow: >> http://www.gwtproject.org/makinggwtbetter.html#workingoncode >> >> To submit the patch use: >> http://www.gwtproject.org/makinggwtbetter.html#submittingpatches >> >> I recently had to move an old svn patch into gerrit and the following >> gave a very simple way to apply it >> >> http://stackoverflow.com/questions/659467/how-to-apply-svn-diff-to-gitjust >> remember to clean up any leftover .orij and .rej files. >> >> Cheers, >> James >> >> >> On 10 June 2013 10:01, Adolfo Panizo >> wrote: >> > >> > Hi, >> > >> > as I wrote in the issue, I am able to do the necessary work for >> solving >> > it. So, can you guide me about the steps that I need to follow in >> order to >> > create a patch properly? >> > >> > Would you like to reuse some code of the old patch? >> > >> > I am going to contact the creator of it because maybe he continues >> > interested on fixing the issue and rebase the patch with the last >> code. >> > >> > Of course if there are other issues related to RichTextArea I can >> solve >> > as well. >> > >> > Thanks in advance, >> > >> > Adolfo. >> > >> > >> > -- >> > 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 unsubscrib
[gwt-contrib] Change in gwt[master]: Ensure clinits get called for JSO instance methods.
Roberto Lublinerman has posted comments on this change.
Change subject: Ensure clinits get called for JSO instance methods.
..
Patch Set 2: Code-Review+1
(1 comment)
File dev/core/src/com/google/gwt/dev/jjs/impl/MethodInliner.java
Line 172: if (program.isStaticImpl(x.getTarget())
&& !program.isJavaScriptObject(x.getTarget().getEnclosingType())) {
Is the extra condition needed? I am not too familiar with how the compiler
handles JSOs but it seems odd to me that statified methods are treated
differently.
--
To view, visit https://gwt-review.googlesource.com/3361
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Colin Alworth
Gerrit-Reviewer: Colin Alworth
Gerrit-Reviewer: John A. Tamplin
Gerrit-Reviewer: Leeroy Jenkins
Gerrit-Reviewer: Matthew Dempsky
Gerrit-Reviewer: Roberto Lublinerman
Gerrit-HasComments: Yes
--
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] Work to do for bug 3042
Another possibility would be to develop a nicer GWT RichTextArea as a separate open source project. There's no reason it has to be in core GWT right away and you'll be able to work faster that way. With real-world usage, you'll probably learn a few things that will make it better quality if we do merge it back to core later. However, if you have to patch GWT to make it work, that is the sort of thing that should be contributed back to GWT. On Thu, Jun 13, 2013 at 10:03 PM, Manuel Carrasco Moñino wrote: > In my opinion, having the tool-bar in gwt makes perfectly sense, > RichTextArea is almost unusable without a bar in any project. It's > plenty of gwt projects which have copied and pasted the code from the > showcase. > > I think that you should face this issue in some steps: > 1.- Listen to GWT contributors for the convenience of moving > RichTextToolbar from samples to gwt. So maintain live this thread > until you get enough feedback. > 2.- Send a first patch just moving the code from show-case to gwt > (showcase should use the new code) > 3.- When the patch were accepted, continue adding other features like > adding/removing widgets from the toolbar, or a panel grouping > RichTextArea + RichTextToolbar, etc. because each thing needs a > different review/discussion. > > - Manolo > > On Tue, Jun 11, 2013 at 7:25 PM, Adolfo Panizo Touzon > wrote: > > Oh! Sorry I saw you were the owner and I thought you had plenty of > > responsability. > > > > Thanks, but everything is fine, the installation process is quite > > simple/clear, so, all is up and running. :D. > > > > Keep an eye into the Issue 1127 because maybe you are interested in > giving > > instructions related to both issues. > > > > Thanks, > > > > Adolfo. > > > > > > On Tue, Jun 11, 2013 at 10:28 AM, Daniel Kurka > wrote: > >> > >> Hi Adolfo, > >> > >> this is not my issue and I am not solely responsible for it. > >> > >> We should see wait and see if anybody opposes to adding this to GWT, > >> before you actually start working on it, so that your time will not be > >> wasted. > >> On the other hand you can already setup your IDE and tools to be able to > >> start. James pointed out the resources. If there is anything wrong / > unclear > >> in those resources please let us know. Or you could even send a patch > for > >> the homepage to be updated. > >> > >> - Daniel > >> > >> > >> On Mon, Jun 10, 2013 at 8:07 PM, Adolfo Panizo Touzon > >> wrote: > >>> > >>> Thanks James! > >>> > >>> But I have done those steps yet (indeed I read in that link I should > ask > >>> here first :D) . When I said the necessary work I meant the steps for > >>> develop the RichTextArea according to the GWT steering committee (for > this > >>> issue I think Daniel is responsible) so I need to wait for his opinion. > >>> > >>> Thanks anyway for your quick response. > >>> > >>> Adolfo. > >>> > >>> > >>> On Mon, Jun 10, 2013 at 1:02 PM, James Horsley < > james.hors...@gmail.com> > >>> wrote: > > Adolfo, > > To get the source checked out and compiling follow: > http://www.gwtproject.org/makinggwtbetter.html#workingoncode > > To submit the patch use: > http://www.gwtproject.org/makinggwtbetter.html#submittingpatches > > I recently had to move an old svn patch into gerrit and the following > gave a very simple way to apply it > > http://stackoverflow.com/questions/659467/how-to-apply-svn-diff-to-gitjust > remember to clean up any leftover .orij and .rej files. > > Cheers, > James > > > On 10 June 2013 10:01, Adolfo Panizo wrote: > > > > Hi, > > > > as I wrote in the issue, I am able to do the necessary work for > solving > > it. So, can you guide me about the steps that I need to follow in > order to > > create a patch properly? > > > > Would you like to reuse some code of the old patch? > > > > I am going to contact the creator of it because maybe he continues > > interested on fixing the issue and rebase the patch with the last > code. > > > > Of course if there are other issues related to RichTextArea I can > solve > > as well. > > > > Thanks in advance, > > > > Adolfo. > > > > > > -- > > 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 rec
[gwt-contrib] Change in gwt[master]: Ensure clinits get called for JSO instance methods.
Colin Alworth has posted comments on this change.
Change subject: Ensure clinits get called for JSO instance methods.
..
Patch Set 2:
(2 comments)
File user/test/com/google/gwt/dev/jjs/test/JsoTest.java
Line 49: static final class ClinitStaticFieldFirst extends
JavaScriptObject {
Correct - the commit message documents this, but I'll stick a comment too.
Line 54: if (FIELD == null) {
Again, commit message touched on it. The bug only manifests in compiled
code, and the compiler will inline this if it is too simple. I was going
for the simplest code I could write that would not be optimized out (at
least in draft mode) without using JSNI. Not that there is an issue with
JSNI here, just that I wanted to keep the issue on track for following Java
semantics. Once the method gets inlined, the bug goes away, since the
outside code is accessing the field, and any static field access requires a
clinit (which the compiler doesn't forget before this patch).
--
To view, visit https://gwt-review.googlesource.com/3361
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Colin Alworth
Gerrit-Reviewer: Colin Alworth
Gerrit-Reviewer: John A. Tamplin
Gerrit-Reviewer: Leeroy Jenkins
Gerrit-Reviewer: Matthew Dempsky
Gerrit-Reviewer: Roberto Lublinerman
Gerrit-HasComments: Yes
--
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] Change in gwt[master]: Ensure clinits get called for JSO instance methods.
Matthew Dempsky has posted comments on this change.
Change subject: Ensure clinits get called for JSO instance methods.
..
Patch Set 2:
(3 comments)
File user/test/com/google/gwt/dev/jjs/test/JsoTest.java
Line 49: static final class ClinitStaticFieldFirst extends
JavaScriptObject {
You have three identical class definitions here. I suspect that's because
you have multiple test scenarios, and clinits aren't undoable. It would be
nice to have a comment explaining that, so people don't come later on and
think they can refactor the code and eliminate the extra tests. :)
Line 54: if (FIELD == null) {
What's the point of all these 'if' statements? It looks like you should be
able to eliminate them.
If they're necessary, can you please add a comment explaining why?
Line 84: static final class ClinitStaticMethodFirst extends
JavaScriptObject {
Nit: Blank line before new class definition.
--
To view, visit https://gwt-review.googlesource.com/3361
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: If09885382bcf2d6c149cd8e48bfdd3ae527d67cb
Gerrit-PatchSet: 2
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Colin Alworth
Gerrit-Reviewer: Colin Alworth
Gerrit-Reviewer: John A. Tamplin
Gerrit-Reviewer: Leeroy Jenkins
Gerrit-Reviewer: Matthew Dempsky
Gerrit-Reviewer: Roberto Lublinerman
Gerrit-HasComments: Yes
--
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] Change in gwt[master]: FileUpload: extending FocusWidget instead of Widget so as it...
Matthew Dempsky has posted comments on this change.
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.
..
Patch Set 5:
(2 comments)
File user/src/com/google/gwt/user/client/ui/FileUpload.java
Line 44: * The developer should be aware that most browsers do not allow
to style
"do not allow to style" here sounds funny to me. Maybe "do not allow
styling"?
Line 209: public void click() {
Is "click" the best name for this method? Maybe something more explicitly
explaining why the user would want to call it,
like "openFileSelectionDialog()"?
--
To view, visit https://gwt-review.googlesource.com/3211
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: I4bc3c0991c5025a10a14b2f04ece6d91e11bcddb
Gerrit-PatchSet: 5
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Manuel Carrasco Moñino
Gerrit-Reviewer: Daniel Kurka
Gerrit-Reviewer: Leeroy Jenkins
Gerrit-Reviewer: Manuel Carrasco Moñino
Gerrit-Reviewer: Matthew Dempsky
Gerrit-Reviewer: Patrick Tucker
Gerrit-Reviewer: Thomas Broyer
Gerrit-HasComments: Yes
--
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] Issue 8083, needs some input from GWT team
Okay, fair enough. Making BigDecimal deserialize faster would certainly be a good thing. I just don't want it to result in hard-to-diagnose errors if there's some kind of mismatch between client and server. If there's any difference then we should probably have a configuration property or an annotation on the remote service interface to turn laziness on. On Fri, Jun 14, 2013 at 1:02 AM, David wrote: > Hi, > > Theoretically you are absolutely right. But practically is another > discussion, I am talking about thousands of lines that need to change just > for the GUI tier limitations. The GUI is just a fraction of the application > because the same Request/Response objects are used internally as well > (command pattern). Redesigning the entire application because of a > limitation of the GUI is nuts. But in the way we use BigInteger, I > understand your point of view. > > But the same problem is there with BigDecimal (somebody else filled an > issue so I did not bother to create a duplicate, it is marked as assume > stale). > > We show records with BigDecimal in Cell tables. Again RPC is slow here. > While the user will only click on certain records to make modifications. > Again I could refactor to wait with conversion to BigDecimal until the user > changes a value (to validate), but in this case BigDecimal was the right > data-type to use and it is not nice to have to redesign an application > because the RPC system of GWT has limitations. > > David > > > On Thu, Jun 13, 2013 at 10:20 PM, Brian Slesinsky wrote: > >> I agree; this seems like a workaround for one application that picked the >> wrong datatype. Maybe we should warn about BigDecimal being slow somewhere? >> If someone wants to do some performance tests of GWT-RPC serialization, >> publishing the results would be useful to the community. >> >> My recommendation in this case would be create a new class named "Id" or >> Key" that simply contains the BigDecimal, then modify the code to use it, >> then change the implementation to store the data in a string field instead. >> In the end you'll have more readable code. >> >> - Brian >> >> >> On Thu, Jun 13, 2013 at 12:03 PM, David wrote: >> >>> John, >>> >>> Well, if I don't have support for this patch then I better stop working >>> on it. I can understand that this is not seen as a priority for GWT. Worst >>> case I just replace the BigInteger/BigDecimal class in the project itself, >>> that is basically what I did right now. >>> >>> Oracle sequences can be configured as a range between -10ˆ-26 and 10ˆ27. >>> The Oracle JDBC drivers return >>> a BigInteger if you force it to the extremes. >>> >>> Changing the application is not feasible, that will be too much work, we >>> are talking about many thousands of dependencies in a huge codebase where >>> BigIntegers and BigDecimals are used - while handling this optimisation on >>> the RPC level can be done in just a few lines of code. >>> >>> In many cases we send large lists of objects that contain BigInteger, >>> BigDecimals but only a few will actually be interacted with. So in that >>> case we only need to convert the Strings to BigInteger (or BigDecimal) when >>> really needed. >>> >>> David >>> >>> On Thu, Jun 13, 2013 at 7:52 PM, John A. Tamplin wrote: >>> On Thu, Jun 13, 2013 at 3:14 AM, David wrote: > The lazy parsing would only happen during deserialisation in the > client. I think it is safe to assume that a BigInteger created through > toString on the server will not result in a parse exception in the client > code - or are there known incompatibilities ? > > I don't want that the regular constructor of BigInteger( String ) or > BigInteger( String, int) would behave differently than before. Not even in > the client when those BigInts are created in the client. That's why I was > asking about the possibility to have different serialisers on client and > server side. > > As the why, well currently the custom field serializer converts the > BigInteger to a String, the client side needs to parse the string and > convert it to an int array, which involves multiple substring, > Integer.parseInt and multiply and add operations. Somehow IE8 has a > problem > with this. IE9 and other browsers are more efficient, but still that is a > lot of CPU operations that can be avoided in my use case. > > In my particular use case they used BigInteger to represent a key in > the database (oracle uses sequence numbers that are bigger than what can > be > represented with long). That might have not been the best idea, but those > decisions have been made a long time ago, when I was not around. On the > server side there is a usage of equals and compareTo happening, which > would > be hard to implement without a BigInteger, so there is logic in the > choice. > They obviously don't want to have an extra layer of objects to avoid the
[gwt-contrib] Change in gwt[master]: making RootPanel.clear(true) respects GWT loader iframe
Daniel Kurka has posted comments on this change.
Change subject: making RootPanel.clear(true) respects GWT loader iframe
..
Patch Set 4:
(1 comment)
File user/src/com/google/gwt/user/client/ui/RootPanel.java
Line 338: if ("iframe".equalsIgnoreCase(childElement.getTagName())
Done
--
To view, visit https://gwt-review.googlesource.com/3430
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5
Gerrit-PatchSet: 4
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka
Gerrit-Reviewer: Daniel Kurka
Gerrit-Reviewer: Leeroy Jenkins
Gerrit-Reviewer: Manuel Carrasco Moñino
Gerrit-Reviewer: Thomas Broyer
Gerrit-HasComments: Yes
--
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] Change in gwt[master]: making RootPanel.clear(true) respects GWT loader iframe
Hello Thomas Broyer, Leeroy Jenkins, I'd like you to reexamine a change. Please visit https://gwt-review.googlesource.com/3430 to look at the new patch set (#5). Change subject: making RootPanel.clear(true) respects GWT loader iframe .. making RootPanel.clear(true) respects GWT loader iframe fixes issue 8200 Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5 --- M user/src/com/google/gwt/user/client/ui/RootPanel.java M user/test/com/google/gwt/user/client/ui/RootPanelTest.java 2 files changed, 44 insertions(+), 3 deletions(-) -- To view, visit https://gwt-review.googlesource.com/3430 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5 Gerrit-PatchSet: 5 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka Gerrit-Reviewer: Daniel Kurka Gerrit-Reviewer: Leeroy Jenkins Gerrit-Reviewer: Manuel Carrasco Moñino Gerrit-Reviewer: Thomas Broyer -- 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] Change in gwt[master]: making RootPanel.clear(true) respects GWT loader iframe
Thomas Broyer has posted comments on this change.
Change subject: making RootPanel.clear(true) respects GWT loader iframe
..
Patch Set 4: Code-Review+1
(1 comment)
File user/src/com/google/gwt/user/client/ui/RootPanel.java
Line 338: if ("iframe".equalsIgnoreCase(childElement.getTagName())
Ah sorry, missed it the first time: use
childElement.hasTagName(IFrameElement.TAG)
--
To view, visit https://gwt-review.googlesource.com/3430
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5
Gerrit-PatchSet: 4
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka
Gerrit-Reviewer: Daniel Kurka
Gerrit-Reviewer: Leeroy Jenkins
Gerrit-Reviewer: Manuel Carrasco Moñino
Gerrit-Reviewer: Thomas Broyer
Gerrit-HasComments: Yes
--
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] Change in gwt[master]: making RootPanel.clear(true) respects GWT loader iframe
Hello Leeroy Jenkins, I'd like you to reexamine a change. Please visit https://gwt-review.googlesource.com/3430 to look at the new patch set (#4). Change subject: making RootPanel.clear(true) respects GWT loader iframe .. making RootPanel.clear(true) respects GWT loader iframe fixes issue 8200 Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5 --- M user/src/com/google/gwt/user/client/ui/RootPanel.java M user/test/com/google/gwt/user/client/ui/RootPanelTest.java 2 files changed, 43 insertions(+), 3 deletions(-) -- To view, visit https://gwt-review.googlesource.com/3430 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5 Gerrit-PatchSet: 4 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka Gerrit-Reviewer: Daniel Kurka Gerrit-Reviewer: Leeroy Jenkins Gerrit-Reviewer: Manuel Carrasco Moñino Gerrit-Reviewer: Thomas Broyer -- 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] Change in gwt[master]: making RootPanel.clear(true) respects GWT loader iframe
Thomas Broyer has posted comments on this change.
Change subject: making RootPanel.clear(true) respects GWT loader iframe
..
Patch Set 1:
(1 comment)
File user/src/com/google/gwt/user/client/ui/RootPanel.java
Line 329: if (!shouldNodeBeRemoved(child)) {
Deattaching/reattaching an iframe should result in reloading its page, and
I don't think that's what we want:
When an iframe element is inserted into a document, the user agent must
create
a nested browsing context, and then process the iframe attributes for the
first
time.
When an iframe element is removed from a document, the user agent must
discard the nested browsing context.
This happens without any unload events firing (the nested browsing context
and
its Document are discarded, not unloaded).
— Source:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-iframe-element
Because it's only about one element (for now, but it should remain only a
handful elements in the future at most), and it's inserted at the end of
the body (well, OK, the module could then add other elements after that,
but the original purpose of clearDom was to clear everything on load), how
about skipping it in each iteration? Would it really slow down things?
while (containerElement.hasChildNodes()) {
Node child = containerElement.getFirstChild();
while (!shouldNodeBeRemoved(child)) {
child = child.getNextSibling();
}
containerElement.removeChild(child);
}
Also, is there really a big difference between hasChildNodes/getFirstChild
and idon't expect clearDom to be used that much, and in 99% of the cases it'll
be used to remove a "loading" message, so losing a few milliseconds
wouldn't really matter as the "loading" message would still be visible in
the interim)
Another alternative would be to search for the first node that we want to
keep and remove everything before it, and repeat that process until we
reached the last child node. Or even better, mix getFirstChild and
getNextSibling to really walk the DOM, skipping the appropriate nodes:
Node child = containerElement.getFirstChild();
while (child != null) {
Node next = child.getNextSibling();
if (shouldNodeBeRemoved(child)) {
containerElement.removeChild(child);
}
child = next;
}
--
To view, visit https://gwt-review.googlesource.com/3430
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka
Gerrit-Reviewer: Daniel Kurka
Gerrit-Reviewer: Leeroy Jenkins
Gerrit-Reviewer: Manuel Carrasco Moñino
Gerrit-Reviewer: Thomas Broyer
Gerrit-HasComments: Yes
--
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] Change in gwt[master]: making RootPanel.clear(true) respects GWT loader iframe
Hello Leeroy Jenkins, I'd like you to reexamine a change. Please visit https://gwt-review.googlesource.com/3430 to look at the new patch set (#3). Change subject: making RootPanel.clear(true) respects GWT loader iframe .. making RootPanel.clear(true) respects GWT loader iframe fixes issue 8200 Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5 --- M user/src/com/google/gwt/user/client/ui/RootPanel.java M user/test/com/google/gwt/user/client/ui/RootPanelTest.java 2 files changed, 49 insertions(+), 2 deletions(-) -- To view, visit https://gwt-review.googlesource.com/3430 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5 Gerrit-PatchSet: 3 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka Gerrit-Reviewer: Daniel Kurka Gerrit-Reviewer: Leeroy Jenkins Gerrit-Reviewer: Manuel Carrasco Moñino -- 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] Change in gwt[master]: making RootPanel.clear(true) respects GWT loader iframei
Hello Leeroy Jenkins, I'd like you to reexamine a change. Please visit https://gwt-review.googlesource.com/3430 to look at the new patch set (#2). Change subject: making RootPanel.clear(true) respects GWT loader iframei .. making RootPanel.clear(true) respects GWT loader iframei fixes issue 8200 Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5 --- M user/src/com/google/gwt/user/client/ui/RootPanel.java M user/test/com/google/gwt/user/client/ui/RootPanelTest.java 2 files changed, 49 insertions(+), 2 deletions(-) -- To view, visit https://gwt-review.googlesource.com/3430 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: newpatchset Gerrit-Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5 Gerrit-PatchSet: 2 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka Gerrit-Reviewer: Daniel Kurka Gerrit-Reviewer: Leeroy Jenkins Gerrit-Reviewer: Manuel Carrasco Moñino -- 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] Change in gwt[master]: making RootPanel.clear(true) respects GWT loader iframei
Daniel Kurka has posted comments on this change.
Change subject: making RootPanel.clear(true) respects GWT loader iframei
..
Patch Set 1:
(2 comments)
File user/src/com/google/gwt/user/client/ui/RootPanel.java
Line 329: if (!shouldNodeBeRemoved(child)) {
If I don't remove them we will see the same node in the next iteration and
since iterating this way is the fastest way to do it. I am okay with
reatttaching an element.
Line 346: && GWT.getModuleName().equals(childElement.getId())) {
You are right this will break IE6 History, but I am not willing to add
extra complexity just to keep IE6 happy, since this will get released with
GWT 2.6, its fine.
--
To view, visit https://gwt-review.googlesource.com/3430
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka
Gerrit-Reviewer: Daniel Kurka
Gerrit-Reviewer: Leeroy Jenkins
Gerrit-Reviewer: Manuel Carrasco Moñino
Gerrit-HasComments: Yes
--
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] Change in gwt[master]: making RootPanel.clear(true) respects GWT loader iframei
Manuel Carrasco Moñino has posted comments on this change.
Change subject: making RootPanel.clear(true) respects GWT loader iframei
..
Patch Set 1:
(2 comments)
File user/src/com/google/gwt/user/client/ui/RootPanel.java
Line 329: if (!shouldNodeBeRemoved(child)) {
Why are you maintaining a list with this nodes?, I think you just skip them
instead of detaching reataching
if (shouldNodeBeRemoved()) {
containerElement.removeChild()
}
Line 346: && GWT.getModuleName().equals(childElement.getId())) {
What about the __gwtHistoryFrame, it is still being used in IE6 History. I
think if we remove it we will break History in this permutation.
I know we are getting rid of IE6 in future releases though.
--
To view, visit https://gwt-review.googlesource.com/3430
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: comment
Gerrit-Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka
Gerrit-Reviewer: Leeroy Jenkins
Gerrit-Reviewer: Manuel Carrasco Moñino
Gerrit-HasComments: Yes
--
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] Manuel (google-web-toolkit-contributors@googlegroups.com)
I've shared an item with you: Manuel https://docs.google.com/document/d/1-y6jum0PO7rRqLu7IBtm1PKxJ21eGlIXl_XDjz2NNcc/edit?usp=sharing It's not an attachment -- it's stored online. To open this item, just click the link above. -- 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] Change in gwt[master]: making RootPanel.clear(true) respects GWT loader iframei
Daniel Kurka has uploaded a new change for review.
https://gwt-review.googlesource.com/3430
Change subject: making RootPanel.clear(true) respects GWT loader iframei
..
making RootPanel.clear(true) respects GWT loader iframei
fixes issue 8200
Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5
---
M user/src/com/google/gwt/user/client/ui/RootPanel.java
M user/test/com/google/gwt/user/client/ui/RootPanelTest.java
2 files changed, 49 insertions(+), 2 deletions(-)
diff --git a/user/src/com/google/gwt/user/client/ui/RootPanel.java
b/user/src/com/google/gwt/user/client/ui/RootPanel.java
index c4929c6..6cf2e06 100644
--- a/user/src/com/google/gwt/user/client/ui/RootPanel.java
+++ b/user/src/com/google/gwt/user/client/ui/RootPanel.java
@@ -15,11 +15,13 @@
*/
package com.google.gwt.user.client.ui;
+import com.google.gwt.core.client.GWT;
import com.google.gwt.core.client.impl.Disposable;
import com.google.gwt.core.client.impl.Impl;
import com.google.gwt.dom.client.BodyElement;
import com.google.gwt.dom.client.Document;
import com.google.gwt.dom.client.Element;
+import com.google.gwt.dom.client.Node;
import com.google.gwt.event.logical.shared.CloseEvent;
import com.google.gwt.event.logical.shared.CloseHandler;
import com.google.gwt.i18n.client.BidiUtils;
@@ -28,8 +30,10 @@
import com.google.gwt.user.client.Event;
import com.google.gwt.user.client.Window;
+import java.util.ArrayList;
import java.util.HashMap;
import java.util.HashSet;
+import java.util.List;
import java.util.Map;
import java.util.Set;
@@ -317,10 +321,32 @@
clear();
if (clearDom) {
- com.google.gwt.user.client.Element containerElement = getElement();
+ List nodesToReAttach = new ArrayList();
+ Element containerElement = getElement();
while (containerElement.hasChildNodes()) {
-containerElement.removeChild(containerElement.getFirstChild());
+Node child = containerElement.getFirstChild();
+
+if (!shouldNodeBeRemoved(child)) {
+ nodesToReAttach.add(child);
+}
+containerElement.removeChild(child);
+ }
+
+ for (Node node : nodesToReAttach) {
+containerElement.appendChild(node);
}
}
}
+
+ private boolean shouldNodeBeRemoved(Node child) {
+if (Element.is(child)) {
+ Element childElement = (Element) child;
+ // do not remove GWT's iframe that is used for loading code
+ if ("iframe".equalsIgnoreCase(childElement.getTagName())
+ && GWT.getModuleName().equals(childElement.getId())) {
+return false;
+ }
+}
+return true;
+ }
}
diff --git a/user/test/com/google/gwt/user/client/ui/RootPanelTest.java
b/user/test/com/google/gwt/user/client/ui/RootPanelTest.java
index d455bd1..5a3ad2e 100644
--- a/user/test/com/google/gwt/user/client/ui/RootPanelTest.java
+++ b/user/test/com/google/gwt/user/client/ui/RootPanelTest.java
@@ -15,6 +15,7 @@
*/
package com.google.gwt.user.client.ui;
+import com.google.gwt.core.client.GWT;
import com.google.gwt.dom.client.DivElement;
import com.google.gwt.dom.client.Document;
import com.google.gwt.dom.client.Element;
@@ -69,6 +70,26 @@
assertEquals(0, rootPanel.getElement().getChildCount());
}
+ public void testClearRootPanelWithGWTFrame() {
+
+RootPanel rootPanel = createDOM("testClearRootPanel");
+
+rootPanel.add(new Button("a"));
+rootPanel.add(new Button("b"));
+
+rootPanel.clear(true);
+assertEquals(0, rootPanel.getElement().getChildCount());
+
+Element iFrame = DOM.createIFrame();
+iFrame.setId(GWT.getModuleName());
+rootPanel.getElement().appendChild(iFrame);
+
+assertEquals(1, rootPanel.getElement().getChildCount());
+
+rootPanel.clear(true);
+assertEquals(1, rootPanel.getElement().getChildCount());
+ }
+
public void testClearRootPanelContainingTextNodes() {
RootPanel rootPanel = createDOM("testClearRootPanelAndDOM");
--
To view, visit https://gwt-review.googlesource.com/3430
To unsubscribe, visit https://gwt-review.googlesource.com/settings
Gerrit-MessageType: newchange
Gerrit-Change-Id: If876b04c453a1d4e170870e97f3a82d0d86599d5
Gerrit-PatchSet: 1
Gerrit-Project: gwt
Gerrit-Branch: master
Gerrit-Owner: Daniel Kurka
--
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] Change in gwt[master]: Adding a DOM clear method to RootPanel
Daniel Kurka has posted comments on this change. Change subject: Adding a DOM clear method to RootPanel .. Patch Set 7: @Manuel good catch. We do not need to care about the History Frame (I looked it up before submitting the patch), but we care about the iframe with code, especially when using Async Loading, because then we still need the frame. I will follow up with a new patch addressing the bug issue 8200 I just filed. -- To view, visit https://gwt-review.googlesource.com/2512 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I712989276142460b91514713eaf8d8f74dbecd7b Gerrit-PatchSet: 7 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka Gerrit-Reviewer: Brian Slesinsky Gerrit-Reviewer: Daniel Kurka Gerrit-Reviewer: Goktug Gokdogan Gerrit-Reviewer: Leeroy Jenkins Gerrit-Reviewer: Manuel Carrasco Moñino Gerrit-Reviewer: Matthew Dempsky Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: No -- 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] Issue 8083, needs some input from GWT team
Hi, Theoretically you are absolutely right. But practically is another discussion, I am talking about thousands of lines that need to change just for the GUI tier limitations. The GUI is just a fraction of the application because the same Request/Response objects are used internally as well (command pattern). Redesigning the entire application because of a limitation of the GUI is nuts. But in the way we use BigInteger, I understand your point of view. But the same problem is there with BigDecimal (somebody else filled an issue so I did not bother to create a duplicate, it is marked as assume stale). We show records with BigDecimal in Cell tables. Again RPC is slow here. While the user will only click on certain records to make modifications. Again I could refactor to wait with conversion to BigDecimal until the user changes a value (to validate), but in this case BigDecimal was the right data-type to use and it is not nice to have to redesign an application because the RPC system of GWT has limitations. David On Thu, Jun 13, 2013 at 10:20 PM, Brian Slesinsky wrote: > I agree; this seems like a workaround for one application that picked the > wrong datatype. Maybe we should warn about BigDecimal being slow somewhere? > If someone wants to do some performance tests of GWT-RPC serialization, > publishing the results would be useful to the community. > > My recommendation in this case would be create a new class named "Id" or > Key" that simply contains the BigDecimal, then modify the code to use it, > then change the implementation to store the data in a string field instead. > In the end you'll have more readable code. > > - Brian > > > On Thu, Jun 13, 2013 at 12:03 PM, David wrote: > >> John, >> >> Well, if I don't have support for this patch then I better stop working >> on it. I can understand that this is not seen as a priority for GWT. Worst >> case I just replace the BigInteger/BigDecimal class in the project itself, >> that is basically what I did right now. >> >> Oracle sequences can be configured as a range between -10ˆ-26 and 10ˆ27. >> The Oracle JDBC drivers return >> a BigInteger if you force it to the extremes. >> >> Changing the application is not feasible, that will be too much work, we >> are talking about many thousands of dependencies in a huge codebase where >> BigIntegers and BigDecimals are used - while handling this optimisation on >> the RPC level can be done in just a few lines of code. >> >> In many cases we send large lists of objects that contain BigInteger, >> BigDecimals but only a few will actually be interacted with. So in that >> case we only need to convert the Strings to BigInteger (or BigDecimal) when >> really needed. >> >> David >> >> On Thu, Jun 13, 2013 at 7:52 PM, John A. Tamplin wrote: >> >>> On Thu, Jun 13, 2013 at 3:14 AM, David wrote: >>> The lazy parsing would only happen during deserialisation in the client. I think it is safe to assume that a BigInteger created through toString on the server will not result in a parse exception in the client code - or are there known incompatibilities ? I don't want that the regular constructor of BigInteger( String ) or BigInteger( String, int) would behave differently than before. Not even in the client when those BigInts are created in the client. That's why I was asking about the possibility to have different serialisers on client and server side. As the why, well currently the custom field serializer converts the BigInteger to a String, the client side needs to parse the string and convert it to an int array, which involves multiple substring, Integer.parseInt and multiply and add operations. Somehow IE8 has a problem with this. IE9 and other browsers are more efficient, but still that is a lot of CPU operations that can be avoided in my use case. In my particular use case they used BigInteger to represent a key in the database (oracle uses sequence numbers that are bigger than what can be represented with long). That might have not been the best idea, but those decisions have been made a long time ago, when I was not around. On the server side there is a usage of equals and compareTo happening, which would be hard to implement without a BigInteger, so there is logic in the choice. They obviously don't want to have an extra layer of objects to avoid the BigInteger in the GWT client since a lot of code is independent of client or server, this would hinder code sharing between the tiers. On the client side these id's are only send forth and back between client and server, no operation is ever performed, so making the custom field serialiser and the BigInteger cooperate gives a big performance improvement. They only operation needed on the client-side is equals, which can also be optimized to do a String comparison when bother have not been parsed a
[gwt-contrib] Change in gwt[master]: Adding a DOM clear method to RootPanel
Manuel Carrasco Moñino has posted comments on this change. Change subject: Adding a DOM clear method to RootPanel .. Patch Set 7: Sorry if I come later to this change, but I am wondering if Should'nt it preserve gwt specific iframes like #__gwtHistoryFrame or #moduleName ? -- To view, visit https://gwt-review.googlesource.com/2512 To unsubscribe, visit https://gwt-review.googlesource.com/settings Gerrit-MessageType: comment Gerrit-Change-Id: I712989276142460b91514713eaf8d8f74dbecd7b Gerrit-PatchSet: 7 Gerrit-Project: gwt Gerrit-Branch: master Gerrit-Owner: Daniel Kurka Gerrit-Reviewer: Brian Slesinsky Gerrit-Reviewer: Daniel Kurka Gerrit-Reviewer: Goktug Gokdogan Gerrit-Reviewer: Leeroy Jenkins Gerrit-Reviewer: Manuel Carrasco Moñino Gerrit-Reviewer: Matthew Dempsky Gerrit-Reviewer: Thomas Broyer Gerrit-HasComments: No -- 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.
