Google Web Toolkit: December 2013

Tuesday, December 31, 2013

Re: JavaFX 2.2 WebView support - possible new User Agent?

So I went back and revisited the issues I'm facing. I appears that most of my issues are related to the sessions not working. In GWT the state is preserved on the client side with no need for sessions on the server. In Grails, JSF and and other web technologies the JSESSIONID needs to be passed back with each response. Without session support many things go wrong. So I'm going to revisit my cookie manager implementation before I continue to document my issues. May I ask what you use for a CookieManager? Another thought is I don't have caching setup and the pages are being reloaded unnecessarily possibly causing Grails and PrimeFaces to misbehave. I will post again as I find out more.

On Tuesday, December 31, 2013 11:15:55 AM UTC-7, Gary Eberhart wrote:

Thank You Michael. I will do so. I'll post my other issues today as well for your review. Thank you for the response. At least I know it's not just me doing something wrong.

--
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+unsubscribe@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: JavaFX 2.2 WebView support - possible new User Agent?

Thank You Michael. I will do so. I'll post my other issues today as well for your review. Thank you for the response. At least I know it's not just me doing something wrong.

Re: JavaFX 2.2 WebView support - possible new User Agent?

Thank You Michael. I will do so. I'll post my other issues today as well for your review. Thank you for the response. At least I know it's not just me doing something wrong.

On Tue, Dec 31, 2013 at 9:07 AM, Michael Prentice <splaktar@gmail.com> wrote:

Here are the Jira issues that I mentioned that affect select elements:

https://javafx-jira.kenai.com/browse/RT-33717

https://javafx-jira.kenai.com/browse/RT-16078

Please vote for them if you think that you may ever consider using the JavaFX WebView.

On Monday, December 30, 2013 9:37:52 PM UTC-5, Michael Prentice wrote:
Yep, we've seen those issues. As I mentioned, I've submitted + voted for a number of select element related bugs. I can try to post links to the bugs in Oracle's Jira tomorrow. Mouse wheel is supposed to be implemented in Java 8. All of the others were pushed out of Java 8 and are currently marked as Java 9. But with enough support, they might be patched in Java 8 after GA.

I'd like to hear about any other issues that you've run into. So far the lacking select element has been the primary pain point for us.

We've been able to make alert and confirm dialogs work with a small amount of code beyond their examples. Of course we'll try to use GWT DialogBoxes for most things (which are working well), but Activities and Places relies on the confirm dialog.

Michael Prentice
GDG Space Coast

On Monday, December 30, 2013 6:59:08 PM UTC-5, Gary Eberhart wrote:

Hello Michael,

I'm having issues with WebView as well. I'm displaying GWT, Grails and PrimeFaces pages in a WebView. I've found several serious functional problems running these web pages in WebView. One of the easiest to explain are the Dropdowns (select elements) that take all available space on the screen, and worse yet do not default to the value of the text. For example I have a drop down for year. The text is 2013 and when you click on the drop down the resulting list starts at 1913 requiring the user to use the little scroll button to get back to 2013. It's just one thing after another. I too have a huge Swing application, 2000 views, that I want to migrate to Web technologies over the next 10 years.

I'd be happy to completely document all of my issues with pictures and all upon request. Please tell me I'm wrong, but it appears WebView fails to render web pages correctly that are otherwise rendered flawlessly by the major browsers?

On Tuesday, November 5, 2013 2:44:13 PM UTC-7, Michael Prentice wrote:

I've been working on a project for the last few months which involves creating new screens for our Swing application. We wanted to start moving towards a web based interface, but we cannot re-do hundreds of screens in a single release/year. So after doing some testing and being satisfied with the HTML5 / CSS 2.1 support in the JavaFX 2.2 Webview, we decided that this was a possible migration path. I am currently working on the first leg of this path and things have gone quite well so far. I chose GWT to build the front-end of the app due to our team's experience with WindowBuilder/Swing and it's focus on Enterprise web applications. Our application is a complex Enterprise app that must be maintained over many years by different people.

Here are some of the results and issues:

Success:
General GWT development has been very productive (learning and architecting the app took considerable time).

Performance running in the WebView has been acceptable on machines with decent GPUs which includes all of our client machines (8 MB video card servers don't do well).
We have been able to implement communication to/from GWT<->JavaScript<->JavaFX<->Swing without any major issues and with very minimal code (some simple JSNI and JSON serialization).

Performance of passing data and opening/closing windows between GWT<->...<->Swing has been very good. Note that we aren't passing large data sets over 1 MB.

The new GWT app fits into our Swing application and feels very nearly 'just like another screen' due to GWT's out of the box styling.
GWT's out of the box styling has worked great and impressed our customers without us having to put forth much effort.

Issues:
The JavaFX WebView does not quite behave like other browsers. It uses the Safari (chrome, webkit) user agent.

Drop downs (ListBox) have rounded edges (unlike Chrome) which we don't really like.
Drop downs (select elements) are not very usable in the WebView. They can't be styled. They show as many elements as fit on the window (extending beyond the borders of the app). Scrolling these drops downs with the mouse wheel isn't supported until JavaFX 8. I've opened some bugs for these issues with Oracle.

Buttons get rounded edges if we override the default GWT style.
Alignment between Chrome and the WebView does not match up for some elements. This causes a number of layout issues.

JavaFX WebView does not support CSS3 and has some of its own rules with vendor extensions of "-fx-". This includes things like "JavaFX CSS does not support CSS layout properties such as float, position, overflow, and width."

"CSS padding and margins properties are supported on some" objects. I tried to use a "padding-left: 22px" today which worked fine in Chrome but had no effect on the same Label in the WebView.

Asking Oracle for fixes or enhancements appears to involve a significantly long wait, even if quickly approved, you may not see your issue resolved for 6-18+ months. It seems to be possible to fix issues yourself via the OpenJDK project, but it appears to require significant time and effort just to get setup/approved to do this.

Now so far none of these issues have been a complete show stopper. But after running into the padding issue today and researching, it seemed like this might be the time to at least attempt to request (I know it is likely not interesting or high priority to most people) a user agent for the JavaFX WebView since it appears to need special handling to work properly (which appears to be one main goals of GWT - to eliminate the troubles of supporting multiple browsers).

I found out that JavaFX has their own CSS rules including a special "-fx-label-padding" rule. There does not appear to be anything like padding-left or padding-top, so you need to specify all 4 ("if a set of four padding values is specified, they are used for the top, right, bottom, and left edges of the region, in that order."). I added this to my existing rule which already has the "padding-left: 22px" rule.

.foo-bar-values {
padding-left: 22px;

-fx-label-padding: 0px 0px 0px 22px;
}

Chrome handled things fine in DevMode (ignored the unknown rule with a warning). But when I loaded up the WebView version, it had no effect. I thought that this was quite odd, so I debugged it with FireBug Lite and apparently that specific CSS rule isn't there in the CSS on the page. I checked my .css file in the .WAR and it is there. Strange...

For more information on how JavaFX WebView handles CSS and defines its own CSS rules see here: http://docs.oracle.com/javafx/2/api/javafx/scene/doc-files/cssref.html

Has anyone else looked into this at all?

Does anyone have any pointers for making GWT/JavaFX play nice together for these 'vendor' extended CSS rules?

Thank you,

Michael Prentice
GDG Space Coast
http://gdgspacecoast.org

--
You received this message because you are subscribed to a topic in the Google Groups "Google Web Toolkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/google-web-toolkit/6Cdo2QpZhd4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to google-web-toolkit+unsubscribe@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: JavaFX 2.2 WebView support - possible new User Agent?

Here are the Jira issues that I mentioned that affect select elements:

https://javafx-jira.kenai.com/browse/RT-33717

https://javafx-jira.kenai.com/browse/RT-16078

Please vote for them if you think that you may ever consider using the JavaFX WebView.

On Monday, December 30, 2013 9:37:52 PM UTC-5, Michael Prentice wrote:

Yep, we've seen those issues. As I mentioned, I've submitted + voted for a number of select element related bugs. I can try to post links to the bugs in Oracle's Jira tomorrow. Mouse wheel is supposed to be implemented in Java 8. All of the others were pushed out of Java 8 and are currently marked as Java 9. But with enough support, they might be patched in Java 8 after GA.

I'd like to hear about any other issues that you've run into. So far the lacking select element has been the primary pain point for us.

We've been able to make alert and confirm dialogs work with a small amount of code beyond their examples. Of course we'll try to use GWT DialogBoxes for most things (which are working well), but Activities and Places relies on the confirm dialog.

Michael Prentice
GDG Space Coast

On Monday, December 30, 2013 6:59:08 PM UTC-5, Gary Eberhart wrote:
Hello Michael,

I'm having issues with WebView as well. I'm displaying GWT, Grails and PrimeFaces pages in a WebView. I've found several serious functional problems running these web pages in WebView. One of the easiest to explain are the Dropdowns (select elements) that take all available space on the screen, and worse yet do not default to the value of the text. For example I have a drop down for year. The text is 2013 and when you click on the drop down the resulting list starts at 1913 requiring the user to use the little scroll button to get back to 2013. It's just one thing after another. I too have a huge Swing application, 2000 views, that I want to migrate to Web technologies over the next 10 years.

I'd be happy to completely document all of my issues with pictures and all upon request. Please tell me I'm wrong, but it appears WebView fails to render web pages correctly that are otherwise rendered flawlessly by the major browsers?

On Tuesday, November 5, 2013 2:44:13 PM UTC-7, Michael Prentice wrote:
I've been working on a project for the last few months which involves creating new screens for our Swing application. We wanted to start moving towards a web based interface, but we cannot re-do hundreds of screens in a single release/year. So after doing some testing and being satisfied with the HTML5 / CSS 2.1 support in the JavaFX 2.2 Webview, we decided that this was a possible migration path. I am currently working on the first leg of this path and things have gone quite well so far. I chose GWT to build the front-end of the app due to our team's experience with WindowBuilder/Swing and it's focus on Enterprise web applications. Our application is a complex Enterprise app that must be maintained over many years by different people.

Here are some of the results and issues:

Success:
General GWT development has been very productive (learning and architecting the app took considerable time).
Performance running in the WebView has been acceptable on machines with decent GPUs which includes all of our client machines (8 MB video card servers don't do well).
We have been able to implement communication to/from GWT<->JavaScript<->JavaFX<->Swing without any major issues and with very minimal code (some simple JSNI and JSON serialization).
Performance of passing data and opening/closing windows between GWT<->...<->Swing has been very good. Note that we aren't passing large data sets over 1 MB.
The new GWT app fits into our Swing application and feels very nearly 'just like another screen' due to GWT's out of the box styling.
GWT's out of the box styling has worked great and impressed our customers without us having to put forth much effort.

Issues:
The JavaFX WebView does not quite behave like other browsers. It uses the Safari (chrome, webkit) user agent.
Drop downs (ListBox) have rounded edges (unlike Chrome) which we don't really like.
Drop downs (select elements) are not very usable in the WebView. They can't be styled. They show as many elements as fit on the window (extending beyond the borders of the app). Scrolling these drops downs with the mouse wheel isn't supported until JavaFX 8. I've opened some bugs for these issues with Oracle.
Buttons get rounded edges if we override the default GWT style.
Alignment between Chrome and the WebView does not match up for some elements. This causes a number of layout issues.
JavaFX WebView does not support CSS3 and has some of its own rules with vendor extensions of "-fx-". This includes things like "JavaFX CSS does not support CSS layout properties such as float, position, overflow, and width."
"CSS padding and margins properties are supported on some" objects. I tried to use a "padding-left: 22px" today which worked fine in Chrome but had no effect on the same Label in the WebView.
Asking Oracle for fixes or enhancements appears to involve a significantly long wait, even if quickly approved, you may not see your issue resolved for 6-18+ months. It seems to be possible to fix issues yourself via the OpenJDK project, but it appears to require significant time and effort just to get setup/approved to do this.
Now so far none of these issues have been a complete show stopper. But after running into the padding issue today and researching, it seemed like this might be the time to at least attempt to request (I know it is likely not interesting or high priority to most people) a user agent for the JavaFX WebView since it appears to need special handling to work properly (which appears to be one main goals of GWT - to eliminate the troubles of supporting multiple browsers).

I found out that JavaFX has their own CSS rules including a special "-fx-label-padding" rule. There does not appear to be anything like padding-left or padding-top, so you need to specify all 4 ("if a set of four padding values is specified, they are used for the top, right, bottom, and left edges of the region, in that order."). I added this to my existing rule which already has the "padding-left: 22px" rule.

.foo-bar-values {
padding-left: 22px;
-fx-label-padding: 0px 0px 0px 22px;
}

Chrome handled things fine in DevMode (ignored the unknown rule with a warning). But when I loaded up the WebView version, it had no effect. I thought that this was quite odd, so I debugged it with FireBug Lite and apparently that specific CSS rule isn't there in the CSS on the page. I checked my .css file in the .WAR and it is there. Strange...

For more information on how JavaFX WebView handles CSS and defines its own CSS rules see here: http://docs.oracle.com/javafx/2/api/javafx/scene/doc-files/cssref.html

Has anyone else looked into this at all?

Does anyone have any pointers for making GWT/JavaFX play nice together for these 'vendor' extended CSS rules?

Thank you,

Michael Prentice
GDG Space Coast
http://gdgspacecoast.org

Monday, December 30, 2013

Re: JavaFX 2.2 WebView support - possible new User Agent?

Yep, we've seen those issues. As I mentioned, I've submitted + voted for a number of select element related bugs. I can try to post links to the bugs in Oracle's Jira tomorrow. Mouse wheel is supposed to be implemented in Java 8. All of the others were pushed out of Java 8 and are currently marked as Java 9. But with enough support, they might be patched in Java 8 after GA.

I'd like to hear about any other issues that you've run into. So far the lacking select element has been the primary pain point for us.

We've been able to make alert and confirm dialogs work with a small amount of code beyond their examples. Of course we'll try to use GWT DialogBoxes for most things (which are working well), but Activities and Places relies on the confirm dialog.

Michael Prentice

GDG Space Coast

On Monday, December 30, 2013 6:59:08 PM UTC-5, Gary Eberhart wrote:

Hello Michael,

I'm having issues with WebView as well. I'm displaying GWT, Grails and PrimeFaces pages in a WebView. I've found several serious functional problems running these web pages in WebView. One of the easiest to explain are the Dropdowns (select elements) that take all available space on the screen, and worse yet do not default to the value of the text. For example I have a drop down for year. The text is 2013 and when you click on the drop down the resulting list starts at 1913 requiring the user to use the little scroll button to get back to 2013. It's just one thing after another. I too have a huge Swing application, 2000 views, that I want to migrate to Web technologies over the next 10 years.

I'd be happy to completely document all of my issues with pictures and all upon request. Please tell me I'm wrong, but it appears WebView fails to render web pages correctly that are otherwise rendered flawlessly by the major browsers?

On Tuesday, November 5, 2013 2:44:13 PM UTC-7, Michael Prentice wrote:
I've been working on a project for the last few months which involves creating new screens for our Swing application. We wanted to start moving towards a web based interface, but we cannot re-do hundreds of screens in a single release/year. So after doing some testing and being satisfied with the HTML5 / CSS 2.1 support in the JavaFX 2.2 Webview, we decided that this was a possible migration path. I am currently working on the first leg of this path and things have gone quite well so far. I chose GWT to build the front-end of the app due to our team's experience with WindowBuilder/Swing and it's focus on Enterprise web applications. Our application is a complex Enterprise app that must be maintained over many years by different people.

Here are some of the results and issues:

Success:
General GWT development has been very productive (learning and architecting the app took considerable time).
Performance running in the WebView has been acceptable on machines with decent GPUs which includes all of our client machines (8 MB video card servers don't do well).
We have been able to implement communication to/from GWT<->JavaScript<->JavaFX<->Swing without any major issues and with very minimal code (some simple JSNI and JSON serialization).
Performance of passing data and opening/closing windows between GWT<->...<->Swing has been very good. Note that we aren't passing large data sets over 1 MB.
The new GWT app fits into our Swing application and feels very nearly 'just like another screen' due to GWT's out of the box styling.
GWT's out of the box styling has worked great and impressed our customers without us having to put forth much effort.

Issues:
The JavaFX WebView does not quite behave like other browsers. It uses the Safari (chrome, webkit) user agent.
Drop downs (ListBox) have rounded edges (unlike Chrome) which we don't really like.
Drop downs (select elements) are not very usable in the WebView. They can't be styled. They show as many elements as fit on the window (extending beyond the borders of the app). Scrolling these drops downs with the mouse wheel isn't supported until JavaFX 8. I've opened some bugs for these issues with Oracle.
Buttons get rounded edges if we override the default GWT style.
Alignment between Chrome and the WebView does not match up for some elements. This causes a number of layout issues.
JavaFX WebView does not support CSS3 and has some of its own rules with vendor extensions of "-fx-". This includes things like "JavaFX CSS does not support CSS layout properties such as float, position, overflow, and width."
"CSS padding and margins properties are supported on some" objects. I tried to use a "padding-left: 22px" today which worked fine in Chrome but had no effect on the same Label in the WebView.
Asking Oracle for fixes or enhancements appears to involve a significantly long wait, even if quickly approved, you may not see your issue resolved for 6-18+ months. It seems to be possible to fix issues yourself via the OpenJDK project, but it appears to require significant time and effort just to get setup/approved to do this.
Now so far none of these issues have been a complete show stopper. But after running into the padding issue today and researching, it seemed like this might be the time to at least attempt to request (I know it is likely not interesting or high priority to most people) a user agent for the JavaFX WebView since it appears to need special handling to work properly (which appears to be one main goals of GWT - to eliminate the troubles of supporting multiple browsers).

I found out that JavaFX has their own CSS rules including a special "-fx-label-padding" rule. There does not appear to be anything like padding-left or padding-top, so you need to specify all 4 ("if a set of four padding values is specified, they are used for the top, right, bottom, and left edges of the region, in that order."). I added this to my existing rule which already has the "padding-left: 22px" rule.

.foo-bar-values {
padding-left: 22px;
-fx-label-padding: 0px 0px 0px 22px;
}

Chrome handled things fine in DevMode (ignored the unknown rule with a warning). But when I loaded up the WebView version, it had no effect. I thought that this was quite odd, so I debugged it with FireBug Lite and apparently that specific CSS rule isn't there in the CSS on the page. I checked my .css file in the .WAR and it is there. Strange...

For more information on how JavaFX WebView handles CSS and defines its own CSS rules see here: http://docs.oracle.com/javafx/2/api/javafx/scene/doc-files/cssref.html

Has anyone else looked into this at all?

Does anyone have any pointers for making GWT/JavaFX play nice together for these 'vendor' extended CSS rules?

Thank you,

Michael Prentice
GDG Space Coast
http://gdgspacecoast.org

Re: How to use gwt-dispatch with its CachingDispatchAsync (GWT, GWTP)?

u mean this link http://blog.hivedevelopment.co.uk/2009/08/google-web-toolkit-gwt-mvp-example.html?

it too complicated for me to understand, i need a much simpler example.

On Tuesday, December 31, 2013 12:59:35 PM UTC+11, Jens wrote:

Have you ever clicked on the very first link in that article? If not, you should do that..

-- J.

Re: How to use gwt-dispatch with its CachingDispatchAsync (GWT, GWTP)?

Have you ever clicked on the very first link in that article? If not, you should do that..

-- J.

Re: menus with UIBinder

Doesn't save you a lot but you can call any setter method through UiBinder and I think you can pass any object to that setter as long as you define it as a UiBinder reference using <ui:with> (not 100% sure, could also be that only String, Enum, Integer, etc are allowed), e.g.

<ui:with field="quitCommand" type="com.google...ScheduledCommand" />

<g:MenuItem scheduledCommand="{quitCommand}" />

and in your Java file

@UiField(provided = true)

ScheduledCommand quitCommand = new ScheduledCommand() {

// ... implement

}

In the future, with Java8 support, this can become

@UiField(provided = true)

ScheduledCommand quitCommand = this::doQuit;

-- J.

How to use gwt-dispatch with its CachingDispatchAsync (GWT, GWTP)?

I found a link http://turbomanage.wordpress.com/2010/03/02/tips-for-using-cachingdispatchasync-with-gwt-dispatch/

But there is no step by step guideline for how to use it.

I am using GWTP (with Gwt2.5).

So Can you provide a very simple example how to use gwt-dispatch with its CachingDispatchAsync?

Re: Completely lost at internationalization (i18n)

On Monday, December 23, 2013 11:24:20 PM UTC+1, Qunit wrote:

I'm completely stumped on I18n. Any help would be greatly appreciated. Here's my info:
- Using mvn 3.0.5
- Using uiBinder
- GWT 2.5.1 with GWTBootstrap
- Eclipse 4.2 with maven integration

All working, except when trying to add I18n for dutch (nl, default) and english (en)

Part of .gwt.xml

<inherits name="com.google.gwt.i18n.I18N" />
<extend-property name="locale" values="nl" />
<extend-property name="locale" values="en" />
<set-property-fallback name="locale" value="en"/>
<set-property name="locale" value="nl"/>

That last line is saying that only "nl" locale will actually be compiled. You probably want value="nl,en", though I've been told that removing the 'default' locale might break a few things (haven't personally noticed anything though).

Example part of uiBinder:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE ui:UiBinder SYSTEM "http://dl.google.com/gwt/DTD/xhtml.ent">
<ui:UiBinder xmlns:ui="urn:ui:com.google.gwt.uibinder"
xmlns:b="urn:import:com.github.gwtbootstrap.client.ui"
xmlns:g="urn:import:com.google.gwt.user.client.ui"
ui:generateFormat='com.google.gwt.i18n.rebind.format.PropertiesFormat'
ui:generateKeys="com.google.gwt.i18n.rebind.keygen.MD5KeyGenerator"
ui:generateLocales="default"

You disabled the 'default' locale, so maybe you'll want ui:generateLocales="en, nl"

Note that this attribute is equivalent to @Generate(locales={}): http://www.gwtproject.org/javadoc/latest/com/google/gwt/i18n/client/LocalizableResource.Generate.html#locales()

…or maybe you meant ui:defaultLocale="en" ? (equivalent to @DefaultLocale)

>
<b:Container>
<b:Container ui:field="signupContainer">
<b:Row>
<b:Paragraph><ui:msg description="Enter user details">Please enter your details to signup</ui:msg></b:Paragraph>
</b:Row>

Part of pom.xml:

<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>gwt-maven-plugin</artifactId>
<version>2.5.1</version>
<executions>
<execution>
<goals>
<goal>compile</goal>
<goal>i18n</goal>
<goal>generateAsync</goal>
</goals>
</execution>
</executions>
<configuration>
<i18nMessagesBundle>com.mongoasis.presentation.i18n.Messages</i18nMessagesBundle>
<runTarget>mongoasis.html</runTarget>
<draftCompile>true</draftCompile>
<optimizationLevel>1</optimizationLevel>
<extraParam>true</extraParam>
</configuration>
</plugin>
According to some documentation I should be able to generate property files using mvn install or mvn gwt:i18n.

"mvn gwt:i18n" is about generating com.google.gwt.i18n.client.Messages interfaces from existing .properties files (from your src/main/resources folder), so it's not what you want here.

However doing that results in errors/warnings the the com.mongoasis.presentation.i18n.Messages file could not be found.

This is probably because gwt:i18n cannot find a com/mongoasis/presentation/i18n/Messages.properties file in src/main/resources (that's the name you gave in i18nMessagesBundle, which is a configuration property for the gwt:i18n goal).

Because of that error, your build fails and the GWT compiler (that would generate properties files from your UiBinder templates) is not run (gwt:i18n runs a generate-sources while gwt:compile runs at prepare-package, which is much later in the Maven lifecycle)

So I create it manually after which it complains that it is ampty. Adding random key-value pairs stops the error message, but nowhere I find MD5 hashed properties to fill in. Event specifying the key manually does not result in the text being replaced with any translated text.
I'm felling lost and alone in a dark world... Who enlightens me?

First, don't use gwt:i18n unless you know you need it. It's only useful for a few specific cases, and even more-specific cases if you consider binding it to the build lifecycle.

The gwt:compile should then generate properties files the <extra> folder (which defaults to target/extra). You'll have to copy those files to your src/main/resources (keeping the same folder hierarchy and file name, possibly making copies for the different locales) and then tweak them. In the subsequent calls to gwt:compile, GWT will use them as sources so the correct translations will appear in the generated JavaScript code. You'll only see the result in DevMode or once compiled to JS.

menus with UIBinder

Hi,

with UIBinder you can define a complex menu structure very quiclkly:

<g:MenuBar ui:field="menuBar">

<g:MenuItem ui:field="itm_Account" text="Account">

<g:MenuBar vertical="true">

<g:MenuItem ui:field="itm_Login" text="Login"/>

<g:MenuItem ui:field="itm_Logout" text="Logout"/>

...

But to use these structures in real-life projects you have to blow them with a lot of boilerplate code like this:

itm_Login.setScheduledCommand

(

new ScheduledCommand ()

{

public void execute ()

{

Window.alert ("process command: Login");

}

);

This can be very painful If you have a complex menu structure, especially when thinking about roles and rights.

Are there any methods to do this in a more compact way?

Thanks

Magnus

Re: JavaFX 2.2 WebView support - possible new User Agent?

Hello Michael,

I'm having issues with WebView as well. I'm displaying GWT, Grails and PrimeFaces pages in a WebView. I've found several serious functional problems running these web pages in WebView. One of the easiest to explain are the Dropdowns (select elements) that take all available space on the screen, and worse yet do not default to the value of the text. For example I have a drop down for year. The text is 2013 and when you click on the drop down the resulting list starts at 1913 requiring the user to use the little scroll button to get back to 2013. It's just one thing after another. I too have a huge Swing application, 2000 views, that I want to migrate to Web technologies over the next 10 years.

I'd be happy to completely document all of my issues with pictures and all upon request. Please tell me I'm wrong, but it appears WebView fails to render web pages correctly that are otherwise rendered flawlessly by the major browsers?

On Tuesday, November 5, 2013 2:44:13 PM UTC-7, Michael Prentice wrote:

I've been working on a project for the last few months which involves creating new screens for our Swing application. We wanted to start moving towards a web based interface, but we cannot re-do hundreds of screens in a single release/year. So after doing some testing and being satisfied with the HTML5 / CSS 2.1 support in the JavaFX 2.2 Webview, we decided that this was a possible migration path. I am currently working on the first leg of this path and things have gone quite well so far. I chose GWT to build the front-end of the app due to our team's experience with WindowBuilder/Swing and it's focus on Enterprise web applications. Our application is a complex Enterprise app that must be maintained over many years by different people.

Here are some of the results and issues:

Success:
General GWT development has been very productive (learning and architecting the app took considerable time).
Performance running in the WebView has been acceptable on machines with decent GPUs which includes all of our client machines (8 MB video card servers don't do well).
We have been able to implement communication to/from GWT<->JavaScript<->JavaFX<->Swing without any major issues and with very minimal code (some simple JSNI and JSON serialization).
Performance of passing data and opening/closing windows between GWT<->...<->Swing has been very good. Note that we aren't passing large data sets over 1 MB.
The new GWT app fits into our Swing application and feels very nearly 'just like another screen' due to GWT's out of the box styling.
GWT's out of the box styling has worked great and impressed our customers without us having to put forth much effort.

Issues:
The JavaFX WebView does not quite behave like other browsers. It uses the Safari (chrome, webkit) user agent.
Drop downs (ListBox) have rounded edges (unlike Chrome) which we don't really like.
Drop downs (select elements) are not very usable in the WebView. They can't be styled. They show as many elements as fit on the window (extending beyond the borders of the app). Scrolling these drops downs with the mouse wheel isn't supported until JavaFX 8. I've opened some bugs for these issues with Oracle.
Buttons get rounded edges if we override the default GWT style.
Alignment between Chrome and the WebView does not match up for some elements. This causes a number of layout issues.
JavaFX WebView does not support CSS3 and has some of its own rules with vendor extensions of "-fx-". This includes things like "JavaFX CSS does not support CSS layout properties such as float, position, overflow, and width."
"CSS padding and margins properties are supported on some" objects. I tried to use a "padding-left: 22px" today which worked fine in Chrome but had no effect on the same Label in the WebView.
Asking Oracle for fixes or enhancements appears to involve a significantly long wait, even if quickly approved, you may not see your issue resolved for 6-18+ months. It seems to be possible to fix issues yourself via the OpenJDK project, but it appears to require significant time and effort just to get setup/approved to do this.
Now so far none of these issues have been a complete show stopper. But after running into the padding issue today and researching, it seemed like this might be the time to at least attempt to request (I know it is likely not interesting or high priority to most people) a user agent for the JavaFX WebView since it appears to need special handling to work properly (which appears to be one main goals of GWT - to eliminate the troubles of supporting multiple browsers).

I found out that JavaFX has their own CSS rules including a special "-fx-label-padding" rule. There does not appear to be anything like padding-left or padding-top, so you need to specify all 4 ("if a set of four padding values is specified, they are used for the top, right, bottom, and left edges of the region, in that order."). I added this to my existing rule which already has the "padding-left: 22px" rule.

.foo-bar-values {
padding-left: 22px;
-fx-label-padding: 0px 0px 0px 22px;
}

Chrome handled things fine in DevMode (ignored the unknown rule with a warning). But when I loaded up the WebView version, it had no effect. I thought that this was quite odd, so I debugged it with FireBug Lite and apparently that specific CSS rule isn't there in the CSS on the page. I checked my .css file in the .WAR and it is there. Strange...

For more information on how JavaFX WebView handles CSS and defines its own CSS rules see here: http://docs.oracle.com/javafx/2/api/javafx/scene/doc-files/cssref.html

Has anyone else looked into this at all?

Does anyone have any pointers for making GWT/JavaFX play nice together for these 'vendor' extended CSS rules?

Thank you,

Michael Prentice
GDG Space Coast
http://gdgspacecoast.org

Re: Open Session In View not working (locator?)

On Monday, December 30, 2013 8:17:07 PM UTC+1, Yan wrote:

Hi there,

I am integrating GWT 2.5.1 with Spring 3.0 backend. Run into a problem that OSIVP should fix but it is not.

A parent object contains a list of children objects, both are EntityProxy. On client side, I update the child proxy and my Server side API simply saves the parent. On the server side, my updates to the child object disappears by the time server business logic is invoked. My transaction starts and commits in business service layer. I have already used one single entity manager instance per request by using ThreadLocal.

Without using OSIVP, I did observe if I explicitly start a transaction in my request factory servlet when request comes in, and then commit the transaction in the servlet at the end, the problem is fixed. Therefore, I have to group everything under the same transaction (inside servlet, rather than in service layer), in addition to use one single entity manager pre request, is that correct?

No. Transactions really should be scoped to the service methods at most.

Everyone said that the fix is to use OSIVP, however, I do not see it is fixing the problem afterwards. For whatever reason, using OSIVP does not have the same effect.

1) In my EntityLocator class, how do I get entityManager? Some has posted this code, this is what I used. But, does not it start a new entity manager rather than using what is attached to the thread?

private void init() {
HttpServletRequest request = RequestFactoryServlet.getThreadLocalRequest();
ApplicationContext context = WebApplicationContextUtils.getWebApplicationContext(request.getSession().getServletContext());
EntityManagerFactory entityManagerFactory = context.getBean(EntityManagerFactory.class);
entityManager = entityManagerFactory.createEntityManager();
// then cache this entityManager in locator instance
}

You should call createEntityManager in a servlet filter prior to the RequestFactoryServlet, or call it in some helper class if you want it initialized lazily.

And you could store that EntityManager in the request's attributes rather than a ThreadLocal (but a ThreadLocal will work too).

That said, I don't know Spring, so there might be other ways to get at the EntityManager than calling createEntityManager and "caching" its result yourself.

Possibly something like ((EntityManagerHolder) TransactionSynchronizationManager.getResource(emf)).getEntityManager(), where "emf" is your singleton EntityManagerFactory.

This code is most likely why your app doesn't work: you're not actually using OSIV.

2) In my DAO class, do I need to declare my entity manager as extended like this? That is what I did.

@PersistenceContext(type=PersistenceContextType.EXTENDED)
private EntityManager em;

I suppose so (I don't know Spring or JPA much)

3) How does Spring OpenEntityManagerInViewFilter start a transaction?

It doesn't, fortunately.

Re: Capturing “Cancel” selection from GWT Activity.mayStop() response

I've detailed my solution here: http://stackoverflow.com/a/20848504/633107

It uses both the AbstractCell#handlesSelection override suggested by Jens and the CellPreviewEvent.Handler suggested by Thomas.

Thank you!

Michael Prentice

GDG Space Coast

On Friday, December 27, 2013 3:17:22 PM UTC-5, Michael Prentice wrote:

I'm running into this same situation today when using a DataGrid (each row mapping to a Place). I think that I'll try out the SelectionModel approach and try to set the selection myself on place changes.

I think that Thomas was trying to refer to this StackOverflow question as the one posted doesn't seem to be related:
http://stackoverflow.com/questions/9069525/capturing-cancel-selection-from-gwt-activity-maystop-response/9075170#9075170

On Tuesday, January 31, 2012 7:06:59 AM UTC-5, Thomas Broyer wrote:
With a CellTable, you can also use a CellPreviewEvent.Handler instead of a custom cell (or you can use a custom SelectionModel that won't update from methods called by the CellTable, and you'll update it "manually" using another specific method, in response to a PlaceChangeEvent).

See also (for those who don't read StackOverflow) http://stackoverflow.com/questions/9074497/request-factory-is-sending-back-the-entire-listentityproxy-even-if-only-one-el

Re: GWT 2.5.1 now available

From the contributors list, it looks like sometime in January. There are a few issues that need to be fixed before release, but people are on vacation for the holidays.

On Sunday, December 29, 2013 9:42:39 PM UTC-5, pierre wrote:

On Monday, November 4, 2013 5:00:56 PM UTC+8, Ed wrote:
According to the timeline there will be a RC on 4th of November
Bring it on... ;)

Coming to the end of 2013, may we know latest estimate 2.6 final release date? Thanks!

Open Session In View not working (locator?)

Hi there,

I am integrating GWT 2.5.1 with Spring 3.0 backend. Run into a problem that OSIVP should fix but it is not.

A parent object contains a list of children objects, both are EntityProxy. On client side, I update the child proxy and my Server side API simply saves the parent. On the server side, my updates to the child object disappears by the time server business logic is invoked. My transaction starts and commits in business service layer. I have already used one single entity manager instance per request by using ThreadLocal.

Without using OSIVP, I did observe if I explicitly start a transaction in my request factory servlet when request comes in, and then commit the transaction in the servlet at the end, the problem is fixed. Therefore, I have to group everything under the same transaction (inside servlet, rather than in service layer), in addition to use one single entity manager pre request, is that correct?

Everyone said that the fix is to use OSIVP, however, I do not see it is fixing the problem afterwards. For whatever reason, using OSIVP does not have the same effect.

1) In my EntityLocator class, how do I get entityManager? Some has posted this code, this is what I used. But, does not it start a new entity manager rather than using what is attached to the thread?

private void init() {

HttpServletRequest request = RequestFactoryServlet.getThreadLocalRequest();

ApplicationContext context = WebApplicationContextUtils.getWebApplicationContext(request.getSession().getServletContext());

EntityManagerFactory entityManagerFactory = context.getBean(EntityManagerFactory.class);

entityManager = entityManagerFactory.createEntityManager();

// then cache this entityManager in locator instance

}

2) In my DAO class, do I need to declare my entity manager as extended like this? That is what I did.

@PersistenceContext(type=PersistenceContextType.EXTENDED)

private EntityManager em;

3) How does Spring OpenEntityManagerInViewFilter start a transaction? I do not see it is happening in its source code, other than registering entity manager to current thread. I think that is my problem. If somehow a transaction is started before the locator method is called, I would have been fine.

I wish someone has a sample project illustrates all this.

Thanks,

Yan

Sunday, December 29, 2013

Re: GWT 2.5.1 now available

On Monday, November 4, 2013 5:00:56 PM UTC+8, Ed wrote:

According to the timeline there will be a RC on 4th of November
Bring it on... ;)

Coming to the end of 2013, may we know latest estimate 2.6 final release date? Thanks!

Re: Latest Google Eclipse update has hosed my Eclipse

After my initial post, I had gone to Eclipse docs and per them had put in:

--vm
C:\Program Files\Java\jdk1.7.0_45\jre\bin\javaw.exe

just above the --vmargs line, but that didn't help. I also tried:

--vm
C:\Progra~1\Java\jdk1.7.0_45\jre\bin\javaw.exe

which has worked with system paths, but still no luck.

But, taking a closer look at your post, I see that I had --vm, and it should have been just one dash: -vm

All is good now :)

On Sunday, December 29, 2013 2:33:57 PM UTC-5, Jens wrote:

You can try to start Eclipse using Java7 instead of Java6:

Open eclipse.ini and add (path is Mac OS specific, so change as needed):

-vm
/Library/Java/JavaVirtualMachines/jdk1.7.0_<BUILDNUMBER>/Contents/Home/bin/java

The Google Plugin itself requires Java7, so Eclipse should be executed under Java7. The Java Version of your projects should be irrelevant.

-- J.

Re: Latest Google Eclipse update has hosed my Eclipse

You can try to start Eclipse using Java7 instead of Java6:

Open eclipse.ini and add (path is Mac OS specific, so change as needed):

-vm

/Library/Java/JavaVirtualMachines/jdk1.7.0_<BUILDNUMBER>/Contents/Home/bin/java

The Google Plugin itself requires Java7, so Eclipse should be executed under Java7. The Java Version of your projects should be irrelevant.

-- J.

Re: Latest Google Eclipse update has hosed my Eclipse

Steve,

Rajeev responded to reports of this problem in the GPE group, here:

https://groups.google.com/d/msg/google-plugin-eclipse/V4MaZEXY24Q/FjR16G28WXIJ

Latest Google Eclipse update has hosed my Eclipse

I just updated my Google plugin for Eclipse, per a notification that popped up this morning.

My current project now shows a lot of errors, and several error dialogs pop up when I try to open an existing GWT project workspace. Java editors and some other panes, like the class outline, just show big red X's.

The errors I get are "JVM version is 1.0.0; version 1.7.0 or later is needed to run Google Plugin for Eclipse."

I can't pull up most of the Google-related properties, either. They show an error popup the first time I go to use them, and then just an error message in the panel after that.

I tried pointing Eclipse to my JRE1.7, but that didn't help. I really hope that I don't need to set 1.7 as the Java version for GWT projects now, since several current projects are tied to 1.6,and changing that is not in my control.

Re: how to reproduce.cache.html error in dev

Hi All,

Thanks you for your reply :)

Sorry I did not replied this post after solving issue, yeah The problem is only null pointer.

I used server push mechanism..it tried to use widget before rendering.

I could not get because I habituate to see java script error in development mode but it's showing in console.

Thanks,

Bhumika
On Friday, 6 December 2013 04:21:42 UTC+5:30, Davide Micheletti wrote:

This is the code

server.tutti_clienti(new AsyncCallback<Cliente>() {

public void onSuccess(Cliente result) {

log = log + " 1 - Cliente ";

tutti_clienti = result;

cliente.addItem("- Seleziona un Cliente -","null");

for(int i=0; i<n_clienti; i++)

cliente.addItem(tutti_clienti.getCliente(i), String.valueOf(tutti_clienti.getId(i)));

}

public void onFailure(Throwable caught) {

log = log + " 1.1 - ERRORE Cliente " + caught;
System.out.println("Errore server.tutti_clienti(): " + caught.getMessage());
}

});

"cliente" is a ListBox and "tutti_clienti" is a compose of ArrayList.
These type of code is written for many ListBox with many differt server call.

The problem is that if i run it on a TomCat server not all of the ListBox are loaded, but if i run it in DebugMode it work.
The error that i retrive in "server" mode are;

NullPointerException OR Fail to call the server (etc etc).

Thanks in advance and sorry for my english.

Il giorno giovedì 5 dicembre 2013, Juan Pablo Gardella ha scritto:

From http://www.gwtproject.org/doc/latest/DevGuideCodingBasicsCompatibility.html:

Several fundamental exceptions implicitly produced by the Java VM, most notably NullPointerException, StackOverflowError, andOutOfMemoryError, do not occur in production mode as such. Instead, aJavaScriptException is produced for any implicitly generated exceptions. This is because the nature of the underlying JavaScript exception cannot be reliably mapped onto the appropriate Java exception type.

So, a unhandled error suceded.

2013/12/5 Juan Pablo Gardella <gardellajuanpablo@gmail.com>

I didn't see the java code anywhere. Replace catch (NullPointerExceptione e ) with (Exception e) and put an alert or something to see the problem. It is a NPE in javascript.

Juan

2013/12/5 Davide Micheletti <d.micheletti91@gmail.com>

yes.. u can see it in the code that i posted..

On Thu, Dec 5, 2013 at 7:15 PM, Juan Pablo Gardella <gardellajuanpablo@gmail.com> wrote:

Do you have a catch for NullPointerException in the code that is translated to Javascript?

2013/12/5 Davide Micheletti <d.micheletti91@gmail.com>

i think that i did't explain well. The webapp run but never in the same mode. i attach some screen so you can understand.

On Thu, Dec 5, 2013 at 4:38 PM, Pablo Nussembaum <baunax@gmail.com> wrote:
Hi Bhumika,
You can take a look to:
http://www.gwtproject.org/javadoc/latest/com/google/gwt/logging/server/StackTraceDeobfuscator.html
It can be used to de-obfuscate the stacktrace.

also check:
https://groups.google.com/forum/#!topic/google-web-toolkit/jikvFQUJYjk

Regards,
--
Pablo

On 12/05/2013 03:42 AM, Bhumika Thaker wrote:
> Hi All,
>
> In my gwt application, I am facing below error in war but not in
> development.
> This error is not understandable
> can any body suggest how can I reach to this error in development.
>
> com.google.gwt.core.client.JavaScriptException: (TypeError): a.b.k.j
> is null stack: GXd([object Object],[object
> Object])@http://espo.etenders.uk:8081/uk/v4workflow/EEE53ADF84875B770BBA391E60B8948D.cache.html:7116
> HNi([object Object],[object
> Object])@http://espo.etenders.uk:8081/uk/v4workflow/EEE53ADF84875B770BBA391E60B8948D.cache.html:3830
> JNi([object
> Object])@http://espo.etenders.uk:8081/uk/v4workflow/EEE53ADF84875B770BBA391E60B8948D.cache.html:7919
> cG([object Object],[object
> Object],null)@http://espo.etenders.uk:8081/uk/v4workflow/EEE53ADF84875B770BBA391E60B8948D.cache.html:10218
> NF([object Object],[object
> Object])@http://espo.etenders.uk:8081/uk/v4workflow/EEE53ADF84875B770BBA391E60B8948D.cache.html:9321
> gYd([object
> Object])@http://espo.etenders.uk:8081/uk/v4workflow/E

--
Davide Micheletti