Re: JavaFX 2.2 WebView support - possible new User Agent?
I am not running Grails or PrimeFaces on the back-end. Instead we have servlets that connect us to a proprietary back-end system that is written in C and accessed via JNI. While I do have an authentication system written, we are not using it as our enclosing Swing application handles all authentication atm. We do pass the username into GWT via JSNI for logging/requests though. It's certainly not a completely secure implementation atm, but security is not a high priority since the app is internal. Thus we do not use a CookieManager at all. On Tuesday, December 31, 2013 5:58:40 PM UTC-5, Gary Eberhart wrote: 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+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: 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
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 splak...@gmail.comwrote: 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
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. -- 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: 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+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: 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
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
Re: JavaFX 2.2 WebView support - possible new User Agent?
Yep, it does appear that the WebView is not nearly as limited as the
standard JavaFX CSS support.
Apparently the document that I linked (the only I could find about CSS
support in JavaFX) only applies to normal JavaFX development and not to the
capabilities of the WebView itself (based on webkit).
It does appear that padding-left and other related layout properties work
just fine in the JavaFX WebView. There was something stopping my WebView
from loading up all of the CSS (unknown reason). Thus the last few values
(which I needed) weren't available for styling the document.
I did some major cleaning and rebuilding of my project as well as wiping of
all temp and cache files and this issue 'went away on its own'.
I can see the padding applied properly in the WebView now and I can see it
applied in FireBug Lite:
padding-left22px
I had verified that the rule was in my app.css in the .war file, so GWT was
generating and bundling things properly. There appears to have been an
issue somewhere on the JavaFX WebView side.
Thank you for your help!
Michael Prentice
GDG Space Coast
http://gdgspacecoast.org
On Wednesday, November 6, 2013 7:14:38 PM UTC-5, Oliver Krylow wrote:
So, now that I have read through the docs you linked, I suspect you are
confusing different applications of CSS in the java fx technology stack.
The kind of CSS you are talking and linked about is used to style java fx
components themselves, meaning objects in the scene graph. This version of
CSS is based on CSS2.1, as you cited, with slight modifications (for
example the prefixed rules you mentioned).
The CSS, that gets applied to the DOM inside the Webview, is standard CSS
and since the Webview is based on WebKit, I suspect it parses the '-webkit'
prefix, if any (haven't tested this).
Having said this, I have no idea why your initial tries with the
unprefixed padding rules did not apply. You should probably file this as a
bug.
Correct me if I misunderstood the java fx docs.
On Nov 6, 2013 8:25 PM, Chak Lai wrote:
Just wondering how would the JavaFX WebView if you change the style from
GWT, instead from CSS file. For instance:
public static void setFxPadding(com.google.gwt.user.client.Element
element) {
element.getStyle().setProperty(FxPadding, 0px 0px 0px 22px);
}
--
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: JavaFX 2.2 WebView support - possible new User Agent?
On 11/05/13 23:44, Michael Prentice wrote: I've been working on a project for the last few months which involves creating new screens for our Swing application. Just wanted to say Thanks for sharing this. Vassilis -- 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: JavaFX 2.2 WebView support - possible new User Agent?
I've posted this question to StackOverflow here:
http://stackoverflow.com/questions/19816129/how-do-i-left-pad-a-div-in-a-javafx-webview
On Tuesday, November 5, 2013 6:40:08 PM UTC-5, Michael Prentice wrote:
Thank you for the idea about escaping the first dash. It made the CSS
editor in GWT Designer a bit happier (no longer red). But it didn't end up
fixing the issue. I tried the following without any luck as well (all
worked great in Chrome):
.foo-bar-values {
padding: 0px 0px 0px 22px;
}
.foo-bar-values {
margin: 0px 0px 0px 22px;
}
.foo-bar-values {
margin-left: 22px;
}
.foo-bar-values {
padding-left: 22px;
\-fx-label-padding: 0px 0px 0px 22px;
}
.foo-bar-values {
padding-left: 22px;
\-fx-padding: 0px 0px 0px 22px;
}
As far as migration to JavaFX, we did not see a smooth migration path
there. We can't run our Swing screens in a browser and we can't convert
everything to JavaFX in a single release. We also don't want to have half
of our app run in the browser and half in a Swing application. We don't use
Java WebStart for deployment and we aren't able to change the installation
of our client to require users to browse to a certain site to install the
application. It is pushed out Enterprise wide via Enterprise level
installers.
Using web technologies (GWT) hosted in a JavaFX WebView allows for us to
replace a screen at a time (or more) within our current Swing application
without needing to completely change the deployment/installation strategy.
It also minimizes the end user training with each release. Eventually (2-3
years), we will be in a situation where we can replace the last of the
Swing screens and go to a completely web based solution. We are hoping that
Chromium runtime will be available by then so that we can switch straight
to it (installed as part of our app and not by the user or IT) rather than
having to depend on older versions of IE installed throughout the
Enterprise.
*Some other info about JavaFX WebView:*
- In order to handle Confirmation and Alert dialogs, you must
implement handlers for these in your WebEngine JavaFX code. It isn't hard
and it is quite customizable, but it doesn't come out of the box.
- Deploying and testing within the WebView is quite a pain. FireBug
Lite provides for some limited debugging, but with GWT we don't get
anything useful on the Script tab (Access to restricted URI denied.)
So debugging has to be done in DevMode in Chrome or in the WebView via
alert() dialogs (like debugging with printf's ages ago). This is minimized
by the fact that so far our only code that would need to be debugged in
the
WebView is the navigation code that talks between GWT and Swing via JSNI
and JavaFX.
Michael Prentice
GDG Space Coast
http://gdgspacecoast.org
On Tuesday, November 5, 2013 6:06:53 PM UTC-5, Oliver Krylow wrote:
If the CSS snippet you have shown happens to reside in a uibinder file,
try escaping prefixed rules with a \ .
\-fx-label-padding ...
The CSS parser of gwt used to have trouble with those .
Thank you for reporting your experience with the javafx webview. It has
been an interesting read.
Could you explain your decision to migrate to web technologies instead of
migrating to javafx and deploying it in the browser
http://docs.oracle.com/javafx/2/deployment/deployment_toolkit.htm ?
On Nov 5, 2013 10:44 PM, Michael Prentice spla...@gmail.com 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.
Re: JavaFX 2.2 WebView support - possible new User Agent?
Just wondering how would the JavaFX WebView if you change the style from
GWT, instead from CSS file. For instance:
public static void setFxPadding(com.google.gwt.user.client.Element element)
{
element.getStyle().setProperty(FxPadding, 0px 0px 0px 22px);
}
On Wednesday, November 6, 2013 10:33:33 AM UTC-5, Michael Prentice wrote:
I've posted this question to StackOverflow here:
http://stackoverflow.com/questions/19816129/how-do-i-left-pad-a-div-in-a-javafx-webview
On Tuesday, November 5, 2013 6:40:08 PM UTC-5, Michael Prentice wrote:
Thank you for the idea about escaping the first dash. It made the CSS
editor in GWT Designer a bit happier (no longer red). But it didn't end up
fixing the issue. I tried the following without any luck as well (all
worked great in Chrome):
.foo-bar-values {
padding: 0px 0px 0px 22px;
}
.foo-bar-values {
margin: 0px 0px 0px 22px;
}
.foo-bar-values {
margin-left: 22px;
}
.foo-bar-values {
padding-left: 22px;
\-fx-label-padding: 0px 0px 0px 22px;
}
.foo-bar-values {
padding-left: 22px;
\-fx-padding: 0px 0px 0px 22px;
}
As far as migration to JavaFX, we did not see a smooth migration path
there. We can't run our Swing screens in a browser and we can't convert
everything to JavaFX in a single release. We also don't want to have half
of our app run in the browser and half in a Swing application. We don't use
Java WebStart for deployment and we aren't able to change the installation
of our client to require users to browse to a certain site to install the
application. It is pushed out Enterprise wide via Enterprise level
installers.
Using web technologies (GWT) hosted in a JavaFX WebView allows for us to
replace a screen at a time (or more) within our current Swing application
without needing to completely change the deployment/installation strategy.
It also minimizes the end user training with each release. Eventually (2-3
years), we will be in a situation where we can replace the last of the
Swing screens and go to a completely web based solution. We are hoping that
Chromium runtime will be available by then so that we can switch straight
to it (installed as part of our app and not by the user or IT) rather than
having to depend on older versions of IE installed throughout the
Enterprise.
*Some other info about JavaFX WebView:*
- In order to handle Confirmation and Alert dialogs, you must
implement handlers for these in your WebEngine JavaFX code. It isn't hard
and it is quite customizable, but it doesn't come out of the box.
- Deploying and testing within the WebView is quite a pain. FireBug
Lite provides for some limited debugging, but with GWT we don't get
anything useful on the Script tab (Access to restricted URI denied.)
So debugging has to be done in DevMode in Chrome or in the WebView via
alert() dialogs (like debugging with printf's ages ago). This is
minimized
by the fact that so far our only code that would need to be debugged in
the
WebView is the navigation code that talks between GWT and Swing via JSNI
and JavaFX.
Michael Prentice
GDG Space Coast
http://gdgspacecoast.org
On Tuesday, November 5, 2013 6:06:53 PM UTC-5, Oliver Krylow wrote:
If the CSS snippet you have shown happens to reside in a uibinder file,
try escaping prefixed rules with a \ .
\-fx-label-padding ...
The CSS parser of gwt used to have trouble with those .
Thank you for reporting your experience with the javafx webview. It has
been an interesting read.
Could you explain your decision to migrate to web technologies instead
of migrating to javafx and deploying it in the browser
http://docs.oracle.com/javafx/2/deployment/deployment_toolkit.htm ?
On Nov 5, 2013 10:44 PM, Michael Prentice spla...@gmail.com 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).
Re: JavaFX 2.2 WebView support - possible new User Agent?
So, now that I have read through the docs you linked, I suspect you are
confusing different applications of CSS in the java fx technology stack.
The kind of CSS you are talking and linked about is used to style java fx
components themselves, meaning objects in the scene graph. This version of
CSS is based on CSS2.1, as you cited, with slight modifications (for
example the prefixed rules you mentioned).
The CSS, that gets applied to the DOM inside the Webview, is standard CSS
and since the Webview is based on WebKit, I suspect it parses the '-webkit'
prefix, if any (haven't tested this).
Having said this, I have no idea why your initial tries with the unprefixed
padding rules did not apply. You should probably file this as a bug.
Correct me if I misunderstood the java fx docs.
On Nov 6, 2013 8:25 PM, Chak Lai chaklam@gmail.com wrote:
Just wondering how would the JavaFX WebView if you change the style from
GWT, instead from CSS file. For instance:
public static void setFxPadding(com.google.gwt.user.client.Element
element) {
element.getStyle().setProperty(FxPadding, 0px 0px 0px 22px);
}
On Wednesday, November 6, 2013 10:33:33 AM UTC-5, Michael Prentice wrote:
I've posted this question to StackOverflow here: http://stackoverflow.**
com/questions/19816129/how-do-**i-left-pad-a-div-in-a-javafx-**webviewhttp://stackoverflow.com/questions/19816129/how-do-i-left-pad-a-div-in-a-javafx-webview
On Tuesday, November 5, 2013 6:40:08 PM UTC-5, Michael Prentice wrote:
Thank you for the idea about escaping the first dash. It made the CSS
editor in GWT Designer a bit happier (no longer red). But it didn't end up
fixing the issue. I tried the following without any luck as well (all
worked great in Chrome):
.foo-bar-values {
padding: 0px 0px 0px 22px;
}
.foo-bar-values {
margin: 0px 0px 0px 22px;
}
.foo-bar-values {
margin-left: 22px;
}
.foo-bar-values {
padding-left: 22px;
\-fx-label-padding: 0px 0px 0px 22px;
}
.foo-bar-values {
padding-left: 22px;
\-fx-padding: 0px 0px 0px 22px;
}
As far as migration to JavaFX, we did not see a smooth migration path
there. We can't run our Swing screens in a browser and we can't convert
everything to JavaFX in a single release. We also don't want to have half
of our app run in the browser and half in a Swing application. We don't use
Java WebStart for deployment and we aren't able to change the installation
of our client to require users to browse to a certain site to install the
application. It is pushed out Enterprise wide via Enterprise level
installers.
Using web technologies (GWT) hosted in a JavaFX WebView allows for us to
replace a screen at a time (or more) within our current Swing application
without needing to completely change the deployment/installation strategy.
It also minimizes the end user training with each release. Eventually (2-3
years), we will be in a situation where we can replace the last of the
Swing screens and go to a completely web based solution. We are hoping that
Chromium runtime will be available by then so that we can switch straight
to it (installed as part of our app and not by the user or IT) rather than
having to depend on older versions of IE installed throughout the
Enterprise.
*Some other info about JavaFX WebView:*
- In order to handle Confirmation and Alert dialogs, you must
implement handlers for these in your WebEngine JavaFX code. It isn't hard
and it is quite customizable, but it doesn't come out of the box.
- Deploying and testing within the WebView is quite a pain. FireBug
Lite provides for some limited debugging, but with GWT we don't get
anything useful on the Script tab (Access to restricted URI denied.)
So debugging has to be done in DevMode in Chrome or in the WebView via
alert() dialogs (like debugging with printf's ages ago). This is
minimized
by the fact that so far our only code that would need to be debugged in
the
WebView is the navigation code that talks between GWT and Swing via JSNI
and JavaFX.
Michael Prentice
GDG Space Coast
http://gdgspacecoast.org
On Tuesday, November 5, 2013 6:06:53 PM UTC-5, Oliver Krylow wrote:
If the CSS snippet you have shown happens to reside in a uibinder file,
try escaping prefixed rules with a \ .
\-fx-label-padding ...
The CSS parser of gwt used to have trouble with those .
Thank you for reporting your experience with the javafx webview. It has
been an interesting read.
Could you explain your decision to migrate to web technologies instead
of migrating to javafx and deploying it in the browser
http://docs.oracle.com/javafx/**2/deployment/deployment_**toolkit.htmhttp://docs.oracle.com/javafx/2/deployment/deployment_toolkit.htm?
On Nov 5, 2013 10:44 PM, Michael Prentice spla...@gmail.com 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
JavaFX 2.2 WebView support - possible new User Agent?
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
Re: JavaFX 2.2 WebView support - possible new User Agent?
If the CSS snippet you have shown happens to reside in a uibinder file, try
escaping prefixed rules with a \ .
\-fx-label-padding ...
The CSS parser of gwt used to have trouble with those .
Thank you for reporting your experience with the javafx webview. It has
been an interesting read.
Could you explain your decision to migrate to web technologies instead of
migrating to javafx and deploying it in the browser
http://docs.oracle.com/javafx/2/deployment/deployment_toolkit.htm ?
On Nov 5, 2013 10:44 PM, Michael Prentice splak...@gmail.com 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
Re: JavaFX 2.2 WebView support - possible new User Agent?
Thank you for the idea about escaping the first dash. It made the CSS
editor in GWT Designer a bit happier (no longer red). But it didn't end up
fixing the issue. I tried the following without any luck as well (all
worked great in Chrome):
.foo-bar-values {
padding: 0px 0px 0px 22px;
}
.foo-bar-values {
margin: 0px 0px 0px 22px;
}
.foo-bar-values {
margin-left: 22px;
}
.foo-bar-values {
padding-left: 22px;
\-fx-label-padding: 0px 0px 0px 22px;
}
.foo-bar-values {
padding-left: 22px;
\-fx-padding: 0px 0px 0px 22px;
}
As far as migration to JavaFX, we did not see a smooth migration path
there. We can't run our Swing screens in a browser and we can't convert
everything to JavaFX in a single release. We also don't want to have half
of our app run in the browser and half in a Swing application. We don't use
Java WebStart for deployment and we aren't able to change the installation
of our client to require users to browse to a certain site to install the
application. It is pushed out Enterprise wide via Enterprise level
installers.
Using web technologies (GWT) hosted in a JavaFX WebView allows for us to
replace a screen at a time (or more) within our current Swing application
without needing to completely change the deployment/installation strategy.
It also minimizes the end user training with each release. Eventually (2-3
years), we will be in a situation where we can replace the last of the
Swing screens and go to a completely web based solution. We are hoping that
Chromium runtime will be available by then so that we can switch straight
to it (installed as part of our app and not by the user or IT) rather than
having to depend on older versions of IE installed throughout the
Enterprise.
*Some other info about JavaFX WebView:*
- In order to handle Confirmation and Alert dialogs, you must implement
handlers for these in your WebEngine JavaFX code. It isn't hard and it is
quite customizable, but it doesn't come out of the box.
- Deploying and testing within the WebView is quite a pain. FireBug Lite
provides for some limited debugging, but with GWT we don't get anything
useful on the Script tab (Access to restricted URI denied.) So debugging
has to be done in DevMode in Chrome or in the WebView via alert() dialogs
(like debugging with printf's ages ago). This is minimized by the fact that
so far our only code that would need to be debugged in the WebView is the
navigation code that talks between GWT and Swing via JSNI and JavaFX.
Michael Prentice
GDG Space Coast
http://gdgspacecoast.org
On Tuesday, November 5, 2013 6:06:53 PM UTC-5, Oliver Krylow wrote:
If the CSS snippet you have shown happens to reside in a uibinder file,
try escaping prefixed rules with a \ .
\-fx-label-padding ...
The CSS parser of gwt used to have trouble with those .
Thank you for reporting your experience with the javafx webview. It has
been an interesting read.
Could you explain your decision to migrate to web technologies instead of
migrating to javafx and deploying it in the browser
http://docs.oracle.com/javafx/2/deployment/deployment_toolkit.htm ?
On Nov 5, 2013 10:44 PM, Michael Prentice spla...@gmail.comjavascript:
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
