Important videos from GWT Meet-up 2015
I thought I'd share this link to a series of important videos from the recent GWT Meet-up 2015, which was posted on G+ and in the GWT Contributors group: https://www.youtube.com/playlist?list=PL1yReUCGwGvrqscLu1EAyYRPrr0ceEHLE *Summary:* For anyone who wasn't already aware, there are seismic changes coming for GWT. Basically, gwt-user and everything in it will be gradually mothballed, so widgets, GWT-RPC, UiBinder, CssResource, etc. While we're at it, the GWT compiler will probably go too. If the plan stays as presented, everything is going, sooner or later. It looks as though a much simpler and faster Java to JS transpiler is proposed, maybe under a different project name, with optimizations handled by Closure. I welcome corrections if I've got something wrong here. *Editorial:* Having used GWT for a number of years, I think this is a massive but needed change. It looks like a great direction, that maybe could have been taken even sooner. But personally, I now can't see using GWT for new projects until it appears in its new form. We're in a kind of purgatory now where anything you write in GWT may not be easy to maintain, but the new vision is currently just a hope for the future. As for myself, since I've got a project in its early stages, I'll probably be porting everything I have to JavaScript, until I can count on a stable Java to JS transpiler. At that point, I can decide to move some of the code back to Java, if it's not too painful and the benefits to doing so are clear. At the same time, even with years of Java experience, I have to ask myself, why Java? If it's a better language that compiles to JavaScript that we want, there are many: Dart is coming along, and there are more options than there were before. It's speculation to say what an open source Swift will mean, but the external forces affecting these options can play themselves out while JavaScript will likely continue to be stable for years to come. So rather than drag it out, I'd like to see these changes happen ASAP. As it's sometimes said, if you find yourself in a hole, stop digging. I believe that if a stable and fast Java to JS transpiler were released, the community would chip in to help complete JRE emulation or other needed projects, and I'm glad to hear that much of the GWT team is being diverted to compiler work. Thanks to the GWT team for sharing these plans with the community! -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Important videos from GWT Meet-up 2015
There's no technical reason why not Java the language, but as for the infrastructure available for compiling Java to JavaScript and getting convenient bidirectional access to the JavaScript universe for use in a web application, there are more questions now. Let's say you want to use GWT 2.8 and JsInterop with Polymer. You still have to use JSNI to instantiate JavaScript objects, but that's now discouraged because it will go away. Even when GWT 2.8 is released, the implementation of JsInterop itself will change if the GWT compiler is abandoned in favor of the transpiler. JsInterop annotations may then have to change again due to unforeseen circumstances, but that is speculation. Meanwhile, what do you do about RPC, or i18n, for example? You can push more and more functionality into JavaScript, but then you lose some of the benefits of Java. Anything that depends on gwt-user is to be avoided. There is a nice video suggesting what direction to take (https://www.youtube.com/watch?v=0flgI0AMJjkindex=8list=PL1yReUCGwGvrqscLu1EAyYRPrr0ceEHLE), but it's worth thinking through just how different applications will look that are written to these recommendations vs a standard GWT application today. On Friday, June 12, 2015 at 11:42:37 AM UTC+2, Alain wrote: Well the question could also be why not java ? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Important videos from GWT Meet-up 2015
First video, GWT 2.8 and Beyond, starting around 17:20... I'd also like to hear if I misstated or misunderstood something. I listened to all of the videos and in the discussion I heard more about re-writing and renaming than keeping much of anything. On Friday, June 12, 2015 at 3:20:03 PM UTC+2, Thomas Lefort wrote: Is the phasing out of gwt-user something you heard when attending the meetings? It may be a question of interpretation but I don't read the same from the slides. Sounds more like a fork of GWT to me. Of course if all efforts go to the new project, then it is in effect the same thing ;-) may be some clarifications from the GWT contributors would help. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: Important videos from GWT Meet-up 2015
One thing I may have overstated is that there's a slide discussing what *may* be ported forward (Modernizing GWT Applications https://www.youtube.com/watch?v=0flgI0AMJjklist=PL1yReUCGwGvrqscLu1EAyYRPrr0ceEHLEindex=8, around 18:45), which *may* include GSS and ClientBundles, i18n (since that's in a different module from gwt-user), UiBinder, SafeHtmlTemplates and PlaceHistoryMapperGenerator. But then at 32:30 in the same video a mention of probably not with UiBinder, so UiBinder may not stay, particularly if Singular is available which looks like be a much better solution (and they're looking for contributions to that). A name change for GWT is discussed in GWT 2.8 and Beyond https://www.youtube.com/watch?v=ltqWRoJ0S-olist=PL1yReUCGwGvrqscLu1EAyYRPrr0ceEHLEindex=1, 30:35. Not clear what the result of that will be, but if so much changes, a name change would probably be good to shed the baggage. I also like 32:35 in the same video: Any other questions? Is anybody like scared, or, uh, shocked? :) At some point someone discussed making a table of what will and will not be brought forward, so that would be useful for the community to see. And again, I'm really looking forward to seeing the evolution, but it feels like we're still a ways away from that, so knowing what to do in development now is challenging. On Friday, June 12, 2015 at 3:40:59 PM UTC+2, Phineas Gage wrote: I'd also like to hear if I misstated or misunderstood something. I listened to all of the videos and in the discussion I heard more about re-writing and renaming than keeping much of anything. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: GWT compile fails with default Maven directory structure
On Friday, November 21, 2014 8:03:42 PM UTC+1, Thomas Broyer wrote: I can't tell for App Engine, but why would you want a GWT SDK? You're right, I was able to remove the GWT SDK plugin from Eclipse, and it still works using the one from my maven repository. That's not the case for GAE. If I remove it, I get the same error that I fixed yesterday by changing the build order to move my Maven Dependencies below everything else, as I mentioned earlier: GAE SDK /Users/.../.m2/repository/com/google/appengine/appengine-api-1.0-sdk/1.9.15/appengine-api-1.0-sdk-1.9.15.jar failed validation SDK location '/Users/.../.m2/repository/com/google/appengine/appengine-api-1.0-sdk/1.9.15/appengine-api-1.0-sdk-1.9.15.jar' is not a directory To get it working again, I need to: - Reinstall the GAE SDK from GPE - Change the project to use this SDK temporarily in Project Properties Google App Engine. The change won't persist, but it will add the GAE jars to your build classpath. - Again, move the Maven Dependencies below everything else in Project Properties Java Build Path Order and Export This is a GAE things, but I think more GWT users might run into this. So I can ask the GAE guys about it, but it looks like it's been an issue since at least 2011 https://groups.google.com/forum/#!searchin/google-appengine/SDK$20location$20is$20not$20a$20directory/google-appengine/owo4ZM0IiMs/UTOh4AZhQ-cJ, so maybe there's a reason why things are the way they are. Thanks! -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: GWT compile fails with default Maven directory structure
On Friday, November 21, 2014 11:33:48 AM UTC+1, Thomas Broyer wrote: When you use Maven and Eclipse, you import a Maven project (ou create one from within Eclipse), and the GPE detects the use of the gwt-maven-plugin and auto-configures itself, using the GWT dependencies from your Maven project rather than a GWT SDK (so you can really use any GWT version that's available in the Central Repository, whether it's available as an Eclipse plugin or not is irrelevant). I like launching DevMode using the GPE even when using Maven, because it's simpler and more integrated to Eclipse. Thanks, that got me to where gwt:compile is working from the command line or GPE (save the test code path issue I posted about originally, which I'll go to GPE about). I'll work on running stuff later. Here are a few of the main hurdles I ran into: - I had to manually change the build order http://stackoverflow.com/questions/12107612/how-to-run-maven-project-on-google-app-engine/15314586#15314586 in Java Build Path - Order and Export to put my Maven Dependencies below everything else, which seems a little strange. - Where to put resources. I started with everything in src/main/resources to be Maven-like, but realized for GPE and compiling from maven to work, all stuff that needs to be processed by the GWT compiler needs to go in src/main/java. This was an entertaining read https://groups.google.com/forum/#!searchin/codehaus-mojo-gwt-maven-plugin-users/UiBinder/codehaus-mojo-gwt-maven-plugin-users/Y0dqogsT1Zw/QpSSkwO7CHIJ . - The MobileWebApp sample pom.xml https://gwt.googlesource.com/gwt/+/master/samples/mobilewebapp/pom.xml references the maven-gae-plugin, but it seems like that's been superseded by appengine-maven-plugin https://cloud.google.com/appengine/docs/java/tools/maven. - You still want separate GWT and app engine SDKs installed in Eclipse, even though you've also got them in your local maven repository. - In the end, I was better off starting a new Maven project from scratch then trying to migrate my existing one, especially with my connection to a local Subversion repository. Subclipse didn't handle the moves very well and my working copy got corrupted. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
GWT compile fails with default Maven directory structure
I'm in the process of Maven-izing my GWT 2.6.1 project (an intermediate step to start using GWT 2.7.0), and as a first step want to switch to maven style directory structure (as suggested by the Maven GWT Plugin documentation http://mojo.codehaus.org/gwt-maven-plugin/user-guide/project.html), so I make two simple moves: [project]/src = [project]/src/main/java [project]/test = [project]/src/test/java But what happens when I do this is that the regular GWT Compile from the Google Plugin for Eclipse fails with the -strict option, because it tries to compile my test classes as GWT source code, and of course can't find the classes they reference, for example (source files names obfuscated with extra ...'s): [ERROR] Errors in 'file:/.../src/test/java/.../...Test.java' [ERROR] Line 20: No source code is available for type org.junit.Assert; did you forget to inherit a required module? (... repeated with many other files) I'm confused because this doesn't happen with my old directory structure, and I don't know why the GWT compiler would go back up into my test directory to compile classes there. Strangely, it also doesn't happen with this structure, which I accidentally moved to once: [project]/src = [project]/src/java/main [project]/test = [project]/src/java/test It almost seems like the GWT compiler is doing something special with the default Maven directory structure. And any of the solutions I can think of are not very clean: - Not use the Google Plugin for Eclipse, but only use the Maven GWT Plugin, but then I lose some features from the Google Plugin for Eclipse that I want - Not compile with -strict, but then I don't catch other warnings as easily - Use an exclude in my *.gwt.xml source paths to exclude **/*Test.java, but then I might still catch some unintended utility classes in my test package - Not use a parallel package structure for my tests, but then it's not possible to test package protected classes and methods - Not make [project]/src/test/java a source directory in Eclipse, but I don't know what the side effects of that are How are people handling this, or am I missing something? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: GWT compile fails with default Maven directory structure
On Thursday, November 20, 2014 8:47:35 PM UTC+1, Colin Alworth wrote: It sounds like you have non-gwt-capable classes in packages meant for GWT - is that deliberate? For example, test classes to make sure the various server components in your project work, but they are in your .client or .shared package? If they are not, then GWT will totally ignore them, as no .gwt.xml as indicated that those packages are able to be compiled at all. Yes, I have my test classes in the same packages as the classes they test, but the test classes are in a different source directory. It's always been that way, and I like it because tests are easy to find and they have access to package protected classes and methods. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: GWT compile fails with default Maven directory structure
On Friday, November 21, 2014 8:18:19 AM UTC+1, Thomas Broyer wrote: Sounds like a bug or misconfiguration of the GPE. Is the project a Maven project in Eclipse? There might be some hard-coded paths in the GPE (because of limitations of Eclipse) that are only triggered in one or the other mode (Maven vs. simple Eclipse project). E.g. /test being excluded from the GWT Compiler and DevMode classpath in simple projects, and the test sources (defaulting to src/test/java and src/test/resources), as declared in your Maven POM, in Maven projects. Also, this being a GPE issue, you might have better luck in the dedicated Google Group https://groups.google.com/d/forum/google-plugin-eclipse or on StackOverflow. It was created as a Google - Web Application Project. I think you have it here, it seems that when the source folder base name is 'test', it's excluded from the GWT Compiler, but that's not the case for the default Maven style directory structure. Just as a general question, do you keep the GPE installed when you use Maven? Where I'm heading is that maybe I only need GPE for the UiBinder auto-completion and editor features. Compiling, DevMode and testing can all be handled with Maven. GPE doesn't seem to keep up with GWT releases anyway. Thanks for the help... -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
Re: How to use JavaScript to customize both the client and server in a consistent way?
It's true that I can hand-write these explicit bindings for client and
server, and if I can manage to unit test it, it might not be too hard to
maintain, but the writing of these bindings is what I wanted to avoid. It's
looking more and more like I can't avoid it.
For security, I embedded Rhino on the server and implemented a ClassShutter
(http://blog.notdot.net/2009/10/Server-side-JavaScript-with-Rhino) to
restrict all classes except java.lang, and may add a few others. I'm not
yet 100% convinced that this is enough.
I still would _really_ like this to work client-side, if possible, because
while getPrice could be a server call, I have cases where I'd like to call
the customer's script repeatedly to test for something across multiple
dates, for example, which would mean many round-trip calls. Yes, I could
architect the call to call the server only once, but so far doing this
client-side still seems the easiest and lowest latency way, if it's
possible.
In my case, getSomethingUseful is just a placeholder for many methods. I've
got a number of custom methods on my own BasicDate class I've written, for
example (because I need a consistent date class between the client and
server, and since there is no java.util.Calendar on the client side, and
the Date methods are deprecated, using those is too risky.) I would rather
they just be able to call into the classes that I allow them to.
I like Groovy, and wish it could be made to work client side. I'm going to
try this custom glue / explicit bindings approach with JavaScript, and if I
get lost in the woods, I might end up right where you are! Thanks for your
response.
On Monday, May 12, 2014 11:29:29 PM UTC+2, Ignacio Baca Moreno-Torres wrote:
If you only one to expose the JS code to do expressions, you can define a
concrete and reduced context where the expression will be executed. For
example, if you want to evaluate the price, just add all the properties you
may need (probably all properties of the item bean) to the script execution
bindings. The creation of this bindings may not be shared between client
and server, but it's not complicated. Access random internal classes like
MyClass::getSomethingUseful it's a bad idea, it's better to expose explicit
binding, so if you want to expose MyClass::getSomethigUseful you may add a
util object with a getSomethigUseful method, this is safer, and also solves
your client/server problem. Although, the process to add this methods to
the context may also be a little different between client and server.
This reduced context also is a good idea to reduce your second big
problem, the security! Execute dangerous code through this script it's very
easy, and restrict the access it's difficult. There are a lot of articles
and discussions like
http://stackoverflow.com/questions/1399505/sandboxing-jsr-223http://www.google.com/url?q=http%3A%2F%2Fstackoverflow.com%2Fquestions%2F1399505%2Fsandboxing-jsr-223sa=Dsntz=1usg=AFQjCNEPswtww9B4nerJWzT0MQ76C2rcGg.
I try to do something similar, but I end up using Groovy (only server)
because this utility
http://groovy.codehaus.org/api/org/codehaus/groovy/control/customizers/SecureASTCustomizer.html'solves'
the security problem.
On Saturday, May 10, 2014 4:29:56 PM UTC+2, Phineas Gage wrote:
I am writing a GWT app that will be usable by multiple customers. I'd
like for my customers to be able to customize the app, both on the server
side and client side by writing JavaScript. In other words, they could do
things like:
- Set some configuration for their site, like its name, their web site
URL, address, items on their site, etc.
- Write a JavaScript function to, for example, calculate the price for
some item based on its properties. So the price calculation could be done
on both the client and server, and no recompiling would be needed to change
the price calculation.
The beauty of this is that they could write the JavaScript, and it could
be run using JSNI on the client and Rhino on the server, giving consistent
results. This could also get me out of the business of writing a bunch of
administrative UI code to handle the many possibilities for customization
that customers would want, and also give them much more flexibility,
particularly for price calculations, where the customers want endless
flexibility, and writing a rules engine to handle all of those cases would
be very complicated.
Obviously, the JavaScript they write has to be runnable on both the
client and server. And, if it's just a matter of returning primitives or
the customer writing functions that take and return primitives, it's easy.
Simple JavaScript code snippets like this:
var myname='Joe';
function getMyName() { return 'Joe' };
can be syntactically the same for both JSNI and Rhino.
But the fun soon ends. Let's say I want to allow them to call into
methods in Java classes that I've defined, so I can give
Re: How to use JavaScript to customize both the client and server in a consistent way?
Thanks for the idea. The options expand if they can call back to the server, but I was trying to make something work both client and server side. The gwt-exporter project looks promising, as a lot of syntax might be similar between gwt-exporter and Rhino, but it currently has issues with GWT 2.6.0. On Sunday, May 11, 2014 6:53:19 AM UTC+2, Paul Robinson wrote: You could let them write Java code instead and run it in the server only using BeanShell2. Then the syntax and interoperability issues go away. But you have to send results to the client rather than calculating directly on the client. HTH Paul -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
How to use JavaScript to customize both the client and server in a consistent way?
I am writing a GWT app that will be usable by multiple customers. I'd like
for my customers to be able to customize the app, both on the server side
and client side by writing JavaScript. In other words, they could do things
like:
- Set some configuration for their site, like its name, their web site URL,
address, items on their site, etc.
- Write a JavaScript function to, for example, calculate the price for some
item based on its properties. So the price calculation could be done on
both the client and server, and no recompiling would be needed to change
the price calculation.
The beauty of this is that they could write the JavaScript, and it could be
run using JSNI on the client and Rhino on the server, giving consistent
results. This could also get me out of the business of writing a bunch of
administrative UI code to handle the many possibilities for customization
that customers would want, and also give them much more flexibility,
particularly for price calculations, where the customers want endless
flexibility, and writing a rules engine to handle all of those cases would
be very complicated.
Obviously, the JavaScript they write has to be runnable on both the client
and server. And, if it's just a matter of returning primitives or the
customer writing functions that take and return primitives, it's easy.
Simple JavaScript code snippets like this:
var myname='Joe';
function getMyName() { return 'Joe' };
can be syntactically the same for both JSNI and Rhino.
But the fun soon ends. Let's say I want to allow them to call into methods
in Java classes that I've defined, so I can give them an API to do useful
things. The syntax for accessing Java objects from JavaScript is vastly
different between Rhino and JSNI:
// Rhino
com.abc.package.MyClass.getSomethingUseful();
// JSNI: first in Java
public static native String exportGetSomethingUseful() /*-{
getSomethingUseful =
$entry(@com.abc.package.MyClass::getSomethingUseful());
}-*/;
// JSNI: then in JavaScript
getSomethingUseful();
The situation gets more challenging if you want to pass instances of your
own Java classes into JavaScript for their use, or call from JavaScript
into APIs defined in Java. You've got to define host objects in Rhino, and
I'm not even sure how you do it in JSNI without writing glue code by hand
so that they wouldn't have to learn JSNI's arcane syntax,
My question is: I don't think it's possible for the JavaScript syntax to be
the same between JSNI and Rhino without writing some glue code on both the
client and server in JavaScript to insulate them from these syntactical
differences when working with APIs defined in Java. Am I right, or have I
missed anything?
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
Default ScrollPanel disables iOS pinch zooming, how to disable touch support by default?
The default ScrollPanel in GWT includes touch support, but this disables
pinch zooming on iOS devices. The issue is reported for MGWT here:
https://code.google.com/p/mgwt/issues/detail?id=200
You can work around this by disabling touch support on your ScrollPanel, so
I've done this in a MyScrollPanel, something like this:
public class MyScrollPanel extends ScrollPanel {
public MyScrollPanel() {
// disable touch scrolling on iOS, as it affects pinch zooming
final String platform = Navigator.getPlatform();
if (platform.contains(iPad) || platform.contains(iPhone) ||platform
.contains(iPod)) {
setTouchScrollingDisabled(true);
}
}
}
This works well when I have control over the creation of the ScrollPanel,
but sometimes I don't, like when DataGrid creates a CustomScrollPanel
internally. Is there a way to turn off touch scrolling support globally
somehow? Maybe deferred binding and replacing the ScrollPanel class would
work?
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
Re: Appearance of extra scroll bar in GWT Datagrid
I've noticed the same problem. This is not a real fix, because it causes
the scrollbar to be visible all the time, but if you set a custom scrollbar
in webkit, it avoids the problem. For example, add this to your CSS, as it
looks kind of similar to the Mavericks scrollbar, just a little lighter so
it doesn't draw the eye as much:
::-webkit-scrollbar {
width: 7px;
}
::-webkit-scrollbar-thumb {
width: 7px;
-webkit-border-radius:3px;
border-radius:3px;
background:rgba(0,0,0,0.3);
}
I'd rather have a real fix though.
On Saturday, August 10, 2013 11:02:47 PM UTC+2, harshyadav wrote:
Found in GWT 2.5
*Encountered on OS / Browser:*
Mac OSX 10.8.4, Chrome, Safari. This is not an issue on Firefox.
*Detailed description:*
While using the DataGrid, an extra scroll bar is visible.
Please find attached a screenshot form the GWT showcase.
In my application, I am using DataGrid
(http://gwt.googleusercontent.com/samples/Showcase/Showcase.html#!CwDataGrid)
combined with LazyScrolling example provided in the showcase
(http://gwt.googleusercontent.com/samples/Showcase/Showcase.html#!CwCellList).
I am using DataGrid in ui binder as:
h:LazyDataGrid ui:field=itsCellTable pageSize=30 height=520px
width=100% /
LazyDataGrid extends DataGrid to expose grid's scroll panel as:
public ScrollPanel getScrollPanel() {
HeaderPanel header = (HeaderPanel) getWidget();
return (ScrollPanel) header.getContentWidget();
}
This results in appearance of an extra (non-functional) scroll bar when the
page loads (See attached screenshot).
Thanks in advance.
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
Re: GWT sizing issue in iOS 7 Safari (with all apps using DockLayoutPanel?)
It appears that this is a bug in iOS 7 Safari for iPad (only iPad, in
contrast to the post subject) that's well described here:
http://stackoverflow.com/questions/19012135/ios-7-ipad-safari-landscape-innerheight-outerheight-layout-issue
and here:
http://stackoverflow.com/questions/18855642/ios-7-css-html-height-100-692px
My fix in GWT is to fix the height at startup and on orientation changes,
so I just used my existing orientation change detection stuff (copied here
for completeness, but the actual fix code is pretty small):
public final class IpadIos7HeightFix implements IOrientationChangeHandler {
public static void fixHeight() {
RootLayoutPanel.get().setHeight(getWindowInnerHeight() + px);
Window.scrollTo(0, 0);
}
public static native int getWindowInnerHeight() /*-{
return $wnd.innerHeight;
}-*/;
@Override
public void onOrientationChange(final OrientationChangeEvent event) {
fixHeight();
}
}
public interface IOrientationChangeHandler extends EventHandler {
void onOrientationChange(OrientationChangeEvent event);
}
public final class OrientationChangeEvent extends
GwtEventIOrientationChangeHandler {
public static TypeIOrientationChangeHandler TYPE = new
TypeIOrientationChangeHandler();
private Orientation orientation;
public OrientationChangeEvent(final Orientation orientation) {
this.orientation = orientation;
}
@Override
public TypeIOrientationChangeHandler getAssociatedType() {
return TYPE;
}
public Orientation getOrientation() {
return orientation;
}
@Override
protected void dispatch(final IOrientationChangeHandler handler) {
handler.onOrientationChange(this);
}
}
public final class OrientationResizeHandler implements ResizeHandler {
private static final OrientationChangeEvent LANDSCAPE_EVENT = new
OrientationChangeEvent(
Orientation.LANDSCAPE);
private static final OrientationChangeEvent PORTRAIT_EVENT = new
OrientationChangeEvent(
Orientation.PORTRAIT);
private Orientation orientation;
@Override
public void onResize(final ResizeEvent event) {
final Orientation o = event.getWidth() event.getHeight() ?
Orientation.LANDSCAPE
: Orientation.PORTRAIT;
if (orientation != o) {
Lib.getEventBus().fireEvent(
o == Orientation.PORTRAIT ? PORTRAIT_EVENT : LANDSCAPE_EVENT);
orientation = o;
}
}
}
public enum Orientation {
LANDSCAPE,
PORTRAIT;
}
And finally, on startup:
final String userAgent = Navigator.getUserAgent();
if (userAgent.contains(iPad) userAgent.contains(OS 7)) {
IpadIos7HeightFix.fixHeight();
eventBus.addHandler(OrientationChangeEvent.TYPE, new IpadIos7HeightFix());
}
Window.addResizeHandler(new OrientationResizeHandler());
Thanks for the tips...
On Tuesday, February 4, 2014 8:52:40 PM UTC+1, Phineas Gage wrote:
It seems that with all GWT apps using DockLayoutPanel on iOS 7 Safari,
there is a vertical size issue where some content can get cut off. As an
example, take an iPad and check out the GWT Mail sample:
http://gwt.googleusercontent.com/samples/Mail/Mail.html
or even the tab bar in the MGWT showcase:
http://gwt.googleusercontent.com/samples/Showcase/Showcase.html#!CwCheckBox
In both cases, some pixels from the bottom or top of the page can get cut
off. Changing device orientation can make it better, or worse.
Does anyone know of a fix for this?
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
GWT sizing issue in iOS 7 Safari (with all apps using DockLayoutPanel?)
It seems that with all GWT apps using DockLayoutPanel on iOS 7 Safari, there is a vertical size issue where some content can get cut off. As an example, take an iPad and check out the GWT Mail sample: http://gwt.googleusercontent.com/samples/Mail/Mail.html or even the tab bar in the MGWT showcase: http://gwt.googleusercontent.com/samples/Showcase/Showcase.html#!CwCheckBox In both cases, some pixels from the bottom or top of the page can get cut off. Changing device orientation can make it better, or worse. Does anyone know of a fix for this? -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
GWT dev mode memory leak with simple use case
Any widget that is added to the DOM seems to never get garbage collected
when using dev mode, even if it's removed from the DOM. Here is the sample
source, with just two classes:
public class GwtMemEntryPoint implements EntryPoint {
@Override
public void onModuleLoad() {
for (int i = 0; i 3; i++) {
RootLayoutPanel.get().clear();
RootLayoutPanel.get().add(new LeakyWidget());
}
}
}
public final class LeakyWidget extends Label {
private static int count = 0;
public LeakyWidget() {
setText(Hello Leaky Widget + (++count));
}
}
*Configuration*
- OS/X 10.9.1
- Eclipse Kepler SR1
- Eclipse Memory Analyzer Tool 1.3.1
- GWT 2.5.1
- Firefox 26.0
- JDK 1.7.0_51
*To reproduce*
- Run the above application
- Run GC manually (I used jconsole for this)
- Run Eclipse Memory Analyzer to get a heap dump
(http://www.eclipse.org/mat/)
- View the number of instances of LeakyWidget in the heap dump
*What I'd expect*
- The number of instances of LeakyWidget to be 1, which is the only widget
that hasn't yet been removed from the DOM, the one currently displayed
*What actually happens*
- The number of instances of LeakyWidget is still 3. If you keep reloading
the sample, the number of widgets keeps increasing. They are released when
you quit Firefox.
*Question*
So why is this the case, and is it by design? I would like a way to look
for memory leaks in my code in dev mode without compiling to JS and using a
JS debugger, but if this is not possible, and if this leak is by design, it
would be good to know.
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To unsubscribe from this group and stop receiving emails from it, send an email
to google-web-toolkit+unsubscr...@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at http://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/groups/opt_out.
Re: GWT dev mode memory leak with simple use case
OK, that's clear. This simple use case does not leak per the JavaScript profiler in Chrome (note to future readers to compile with at least Output style: Pretty). I was originally tracking down a leak in my own code, but it turns out that doesn't leak in JS either. I suppose that in super dev mode you wouldn't be dealing with this, because you'd be using your debugger and profiler strictly in JS. Thanks for the response. On Thursday, January 30, 2014 1:33:19 PM UTC+1, Jens wrote: FireFox plugin currently has a memory leak: https://groups.google.com/forum/#!searchin/google-web-toolkit-contributors/firefox/google-web-toolkit-contributors/9YUqQ3vzwV4/3mUd4Y9u8GAJ But even if you find memory leaks in Java it does not mean that its a JavaScript memory leak. Also you might have a JavaScript leak thats not a Java leak. So at the end you want to compile your app and use chrome dev tools to look for memory leaks. One memory leak that is very easy to spot in chrome dev tools are detached DOM trees. These are DOM trees that are still referenced by JavaScript code although they are not attached to the document. If you see large numbers of them then it is likely that you clear() some widgets somewhere but JS still has a reference to them. But be aware that not all detached DOM trees are memory leaks. If you have a widget / DOM element that you only insert into the DOM on certain conditions and otherwise is held in memory then its probably fine (e.g. show either this or that view but both views are already created and held in memory). -- J. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscr...@googlegroups.com. To post to this group, send email to google-web-toolkit@googlegroups.com. Visit this group at http://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/groups/opt_out.
dates in DatePicker sometimes fail to be selected on the iPad
Using Safari on an iPad, or the iOS Simulator in XCode, simply go to the GWT showcase for the DatePicker: http://gwt.google.com/samples/Showcase/Showcase.html#!CwDatePicker Most of the time, when you tap a date, it's selected. However, sometimes the DatePicker is left in an in-between state where the date is highlighted yellow (as if the user had hovered over the date with a mouse) but it is not selected. Tap again, and if you're lucky, it's finally selected. The current release is GWT 2.5, and I'm not sure when this problem appeared... -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/Kikx89X2PtYJ. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
ScrollPanel inside DisclosurePanel inside DialogBox does not work on all browsers in OSX Lion
Using GWT 2.4.0, I'm trying to create a DialogBox for errors
containing a message and a stack trace inside a DisclosurePanel, but
in OSX Lion, scrolling doesn't work in Google Chrome and Safari. It
works on Firefox for OSX Lion, IE for XP and Google Chrome for XP. For
the browsers that it doesn't work on, it sometimes begins to scroll
for a few pixels but then stops.
So far I've tried setting the size on the ScrollPanel explicitly,
turning off animation, and using a Grid instead of a FlowPanel for my
dialog layout, but I just can't seem to get it to work.
Here are the UiBinder xml files and associated Java classes:
ErrorDialogBox.ui.xml:
--
?xml version=1.0 encoding=UTF-8?
ui:UiBinder xmlns:ui=urn:ui:com.google.gwt.uibinder
xmlns:g=urn:import:com.google.gwt.user.client.ui
ui:style
.title {
text-align: center;
font-weight: bold;
}
.desc {
}
.stacktrace {
font-family: Courier New;
word-wrap: break-word;
}
/ui:style
g:Grid
g:row
g:customCell
g:HTML styleName={style.title} ui:field='m_th' /
/g:customCell
/g:row
g:row
g:customCell
g:HTML styleName={style.desc} ui:field='m_dh' /
/g:customCell
/g:row
g:row
g:customCell
g:DisclosurePanel animationEnabled=true
g:headerStack Trace:
/g:header
g:ScrollPanel width=390px height=200px
g:HTML styleName={style.stacktrace} ui:field='m_sth' /
/g:ScrollPanel
/g:DisclosurePanel
/g:customCell
/g:row
/g:Grid
/ui:UiBinder
--
ErrorDialogBox.java:
public final class ErrorDialogBox extends DialogBox
{
// UiBinder fields
interface ErrorDialogBoxUiBinder extends UiBinderGrid,
ErrorDialogBox
{
}
private static ErrorDialogBoxUiBinder s_uib =
GWT.create(ErrorDialogBoxUiBinder.class);
@UiField HTML m_th;
@UiField HTML m_dh;
@UiField HTML m_sth;
public ErrorDialogBox(final String sTitle, final String sDesc, final
Throwable t)
{
setTitle(sTitle);
setGlassEnabled(true);
setAnimationEnabled(true);
setModal(true);
final Grid gr = s_uib.createAndBindUi(this);
m_th.setHTML(sTitle);
m_dh.setHTML(sDesc);
m_sth.setHTML(GwtUtility.getStackTraceHtml(t));
setWidget(gr);
}
}
-
And some code to create an error dialog box (where thr is some
Throwable):
final ErrorDialogBox edb = new ErrorDialogBox(Title, Description,
thr);
edb.center();
edb.show();
--
Does anyone know what this is or how to fix / workaround it?
--
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
Re: ScrollPanel inside DisclosurePanel inside DialogBox does not work on all browsers in OSX Lion
Replacing setModal(true) above with setModal(false) works for me and still seems to work in the other browsers. It's hard to say whether that's a bug or not, but setModal(false) avoids it. Many thanks... Pete On Sep 20, 6:17 pm, Jens jens.nehlme...@gmail.com wrote: Can you try and use setModal(false) on your PopupPanel? I don't use setModal(true) as I already have the glasspane active which is in most cases enough. You can also try and change some Mac OS Lion settings: Preferences - General - activate show scrollbars when scrolling. -- J. -- You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-toolkit@googlegroups.com. To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.
Re: how to determine when StackPanel index changes?
It works, thanks...
On Aug 28, 6:57 pm, Chad chad...@gmail.com wrote:
Phineas Gage,
I haven't tried it, but you could probably override either the
showStack or onBrowserEvent method. Probably showStack, something like
this:
@Override
public void showStack(int index) {
super.showStack(index);
if (index == getSelectedIndex()) {
onShowStack();
}
}
And, of course, create an onShowStack method that would only be called
when the stack is changed.
HTH,
Chad
On Aug 28, 1:26 am, Phineas Gage phineas...@gmail.com wrote:
When using a StackPanel, is there any way to listen for when the
selected index of the StackPanel changes?
I see that it can be retrieved with getSelectedIndex() and set with
showStack(index), but there is no apparent way to be called when
someone clicks to set the current index. I'd like to do this so that I
can set a history token and restore the StackPanel to its original
state when the back button is pressed or an external link is used...
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
Google Web Toolkit group.
To post to this group, send email to google-web-toolkit@googlegroups.com
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en
-~--~~~~--~~--~--~---
how to determine when StackPanel index changes?
When using a StackPanel, is there any way to listen for when the selected index of the StackPanel changes? I see that it can be retrieved with getSelectedIndex() and set with showStack(index), but there is no apparent way to be called when someone clicks to set the current index. I'd like to do this so that I can set a history token and restore the StackPanel to its original state when the back button is pressed or an external link is used... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en -~--~~~~--~~--~--~---
Re: user roles for GWT applications
On Aug 20, 4:46 pm, Laird Nelson ljnel...@gmail.com wrote: On Thu, Aug 20, 2009 at 9:39 AM, Zé Vicente josevicentec...@gmail.comwrote: I would say that all you need to do is to use runAsync() to saparate Adm features from regular features and then make sure that on server side you check for each operation, if the user has the good credential to execute it. Bear in mind that unless I've misread the documentation runAsync() will not always split the code where you have asked it to split it. I think the original poster still has a valid point; I'd be curious to see what the GWT guys have to say about this (very, very common) use case. How does one separate admin code from normal user code in a GWT application? Obviously the ultimate answer is to make sure that the server side functionality is protected by an authentication mechanism, so that no matter what you can't run an admin function unless you are authenticated as an admin. But it seems like there should be a way beyond runAsync() to reliably segment application code that is downloaded to the browser. Right...consider this use case: You have two roles, one for manager and one for employee. You wouldn't want the employee downloading the manager's part of the application as well. In there might be sensitive information revealing management policy/procedure, structure or other things that are not intended to be viewed by employees. And in general, even though RPC methods will be protected from being called, it's better if users can't look at the client stubs for sensitive methods to learn about what parameters are passed and what's returned, as that might inadvertently reveal internal info about how the system works, which might be used in other attacks. regards, Phineas --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en -~--~~~~--~~--~--~---
user roles for GWT applications
I would like to implement a GWT application where users log in and are assigned roles, as is typical in many web applications. Based on their role, they would be able to see and use different areas of the application. The trouble when using GWT is, because the entire application is transmitted to the browser (deferred binding is the exception, but more on that later), even people who have no permission to view a certain part of the application have downloaded the (albeit obfuscated) JavaScript code. There was a good discussion about this pertaining to the case of wanting to create an admin area of an application: http://groups.google.com/group/google-web-toolkit/browse_thread/thread/2b32e4d4011076c/cd8553caf7aa6994?lnk=gstq=role#cd8553caf7aa6994 The general consensus was that it's sufficient to protect the data and not the UI. This may be true, in that when a user authenticates, the server now knows that user's role, and each subsequent RPC made with a session ID associated with that user undergoes a role check. Users are denied if they try to execute RPC methods when they don't belong to all of the roles required to execute that method. However, it's still less than ideal for at least two reasons: 1) Even though users cannot execute, for example, administrative RPC methods, by reverse engineering the JavaScript they may still be able to read sensitive information regarding the format or nature of the available administrative requests. Careful developers may be able to avoid revealing such information, but it may not be easy to instruct every developer on the team on how to avoid revealing subtle but security-sensitive clues about the system. 2) Some users will download code that they will not necessarily execute, making the application needlessly larger. So there are a couple of possible solutions to this: 1) If you're only talking about a single role, like administrator, create a separate GWT application for administration and protect that on your web server. Yes, it might be less than ideal in that you can't easily share the same interface with the regular user application, but it should solve the problem. 2) One possibility that could generalize to more roles is to use deferred binding (http://code.google.com/webtoolkit/doc/1.6/ DevGuideCodingBasics.html#DevGuideDeferredBinding). Using replacement with deferred binding, entire code paths might be compiled out of the application for example by, in the user case, not including the administrative tabs. But then you'd have to figure out exactly which files in the war need to be protected (this might not be easy and when re-compiles occur if their name changes you'd have to do it again) and protect them on the web server at a file level. Also, if you have more than just a couple of roles you'd have an explosion in the amount of code that needs to be generated on a compile and on the size of the application stored on the server, because each role would be a new axis for deferred binding. I think this would be 2^R, where R is the number of roles. So if you've got 5 roles, you've got 32 versions of your code. If you multiply that for 5 browsers and 4 languages, now you're talking about 640 versions of your code. It starts to get impractical, doesn't it? Especially when the code in each version is largely duplicated. So has anyone thought of a better solution to this problem, or does anyone know if something is planned for a future GWT release? I didn't see this referred to in the Google I/O video on 2.0 (http:// code.google.com/events/io/sessions/GwtPreviewGoogleWebToolkit2.html). As far as I can tell, the new code splitting stuff is just for reducing the download size and startup time... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en -~--~~~~--~~--~--~---
Re: user roles for GWT applications
On Aug 19, 4:02 pm, mars1412 martin.trum...@24act.at wrote: just my 2 cents: hiding or obfuscating will not stop a detrmined attacker anyway, so there's no reason to worry about that. that does of course not mean, that you shouldn't do it, if it's easy: e.g. of course use the OFB mode when compiling the GWT app just make sure, that all service methods are properly secured on the serverside Yes, hiding or obfuscating doesn't help much. I was hoping for a secure way for users to never even be able to download administrative client code at all, without making it a separate GWT application. Even with runAsync(), users might be able to still retrieve the admin code unless it's protected on a file level on the server, but you have to determine which files to protect and preferably make it a seamless experience for the user so they don't have to provide separate web server credentials to download the admin client code. 2) Some users will download code that they will not necessarily execute, making the application needlessly larger. RunAsync should help * if the user doesn't have the required permission to e.g. open an admin view, then hide the button or menu-element - the user will not see it and it will not get downloaded * if an admin is logged, in you'll of course show the button/ menuelement and if she clicks the button, RunAsync will kick in and the relevant code will be downloaded Good point for reducing size. That will be useful, when GWT 2.0 comes out, as it should be in there. Until then you have to compile on the trunk to use it, I think. Thanks for the response. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to google-web-toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en -~--~~~~--~~--~--~---
GWT internal frames
I would like to create an application that has a series of movable internal frames. It would be nice if these were not iframes so there wouldn't need to be a new request to fetch the content for each frame, so I don't think the Frame class does it for me (plus, those can't be moved). Is there such a thing in GWT as frames or panels that can be moved (dragged by the user or moved programmatically) within the browser window? Resize support isn't necessary in my case, although that would be nice as well. Basically, I'm thinking of a analog to the Swing internal frame... --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups Google Web Toolkit group. To post to this group, send email to Google-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to google-web-toolkit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~--~~~~--~~--~--~---
