Could you check why I can not build this app? github link included

[mitvitaminen]

Hi,

I just can not get this to work. Could someone please check my project, and tell me where I do wrong? If u like do a pullrequest. -> https://github.com/mitvitaminen/crowear_shop

I seem to be a little bit dumb so sorry for inconvinience and thanks in advance

kind regards Chris

[salmonb]

Hi Chris,

I didn't go deep in this first investigation, but my first look will probably disappoint you: I don't think it's possible to compile your app with WebFX. The reason is that there are too many dependencies that can't run in a browser. For example it needs a H2 database. I don't think it makes sense to ask GWT to compile H2 to run in the browser. H2 needs to write the database into local Files, which is something prohibited by browsers. Similar issue with Apache Shiro...

I'm sorry, WebFX isn't a magical tool that can transpile any JavaFX desktop application into a web app. Your app needs to be more compliant with the web ecosystem to get a chance. I think in your case JPro would be a better solution, because your "client" actually runs in a standard JVM on a server (and is therefore not constrained by the browser sandbox). Have you already tried JPro?

[mitvitaminen]

Well this is just a learning project so don"t worry, do you have suggestions for doing security with webfx? The H2 DB will be replaced with some other DB later on like mongoDB or SQL, they will not have this problem i assume? Tahnks for the tipp with jpro. I actually tried it first and it did run quite well, but to make it feel more like a web site (url browsing i.e.) I would have to change the Application class and I do not want to do that because of mvvmfxGuiceApplication I am extending and thus I could not get the Routing of it to work because I would have to change that class to one of jpro. Are there any other libraries that would collide with web fx because I like the client aspect and its scalability more too. Anyways webfx looks like a nice way of deploying and jpro and webfx will give javafx quite a push whichI like because javafx is such a nice lib:D So thanks that you take time to check out my application. Really appreciated. kind regards Chris

Am Mi., 17. Mai 2023 um 16:18 Uhr schrieb Bruno Salmon < @.***>:

Hi Chris,

I didn't go deep in this first investigation, but my first look will probably disappoint you: I don't think it's possible to compile your app with WebFX. The reason is that there are too many dependencies that can't run in a browser. For example it needs a H2 database. I don't think it makes sense to ask GWT to compile H2 to run in the browser. H2 needs to write the database into local Files, which is something prohibited by browsers. Similar issue with Apache Shiro...

I'm sorry, WebFX isn't a magical tool that can transpile any JavaFX desktop application into a web app. Your app needs to be more compliant with the web ecosystem to get a chance. I think in your case JPro would be a better solution, because your "client" actually runs in a standard JVM on a server (and is therefore not constraint by the browser sandbox). Have you already tried JPro?

— Reply to this email directly, view it on GitHub https://github.com/webfx-project/webfx-cli/issues/9#issuecomment-1551484782, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHFAXTWLXLCVSLSAGKBK5ZDXGTM3XANCNFSM6AAAAAAYE67PLE . You are receiving this because you authored the thread.Message ID: @.***>

[salmonb]

Thanks for keeping your interest in WebFX despite this first try! If you have followed the project, you may know that we are currently building an entreprise level app called Modality with WebFX. In the process, we are also building 2 important parts of the WebFX ecosystem: WebFX Stack and WebFX Extras. Their modules have not been published yet (still in incubation in private repos), but the READMEs provide some information (in particular the UI routing, Authn & Authz may interest you). It may take a year to finish all of this, but we will publish some video demos of Modality within a few months that will already demonstrate these features (and the potential of WebFX for enterprise web apps in general).

[mitvitaminen]

Bruno Salmon @.***> schrieb am Mi., 17. Mai 2023, 16:18:

Hi Chris,

I didn't go deep in this first investigation, but my first look will probably disappoint you: I don't think it's possible to compile your app with WebFX. The reason is that there are too many dependencies that can't run in a browser. For example it needs a H2 database. I don't think it makes sense to ask GWT to compile H2 to run in the browser. H2 needs to write the database into local Files, which is something prohibited by browsers. Similar issue with Apache Shiro...

I'm sorry, WebFX isn't a magical tool that can transpile any JavaFX desktop application into a web app. Your app needs to be more compliant with the web ecosystem to get a chance. I think in your case JPro would be a better solution, because your "client" actually runs in a standard JVM on a server (and is therefore not constraint by the browser sandbox). Have you already tried JPro?

— Reply to this email directly, view it on GitHub https://github.com/webfx-project/webfx-cli/issues/9#issuecomment-1551484782, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHFAXTWLXLCVSLSAGKBK5ZDXGTM3XANCNFSM6AAAAAAYE67PLE . You are receiving this because you authored the thread.Message ID: @.***>

[mitvitaminen]

Christian Rocholl @.***> schrieb am Mi., 17. Mai 2023, 16:37:

Well this is just a learning project so don"t worry, do you have suggestions for doing security with webfx? The H2 DB will be replaced with some other DB later on like mongoDB or SQL, they will not have this problem i assume? Tahnks for the tipp with jpro. I actually tried it first and it did run quite well, but to make it feel more like a web site (url browsing i.e.) I would have to change the Application class and I do not want to do that because of mvvmfxGuiceApplication I am extending and thus I could not get the Routing of it to work because I would have to change that class to one of jpro. Are there any other libraries that would collide with web fx because I like the client aspect and its scalability more too. Anyways webfx looks like a nice way of deploying and jpro and webfx will give javafx quite a push whichI like because javafx is such a nice lib:D So thanks that you take time to check out my application. Really appreciated. kind regards Chris

Am Mi., 17. Mai 2023 um 16:18 Uhr schrieb Bruno Salmon < @.***>:

Hi Chris,

I didn't go deep in this first investigation, but my first look will probably disappoint you: I don't think it's possible to compile your app with WebFX. The reason is that there are too many dependencies that can't run in a browser. For example it needs a H2 database. I don't think it makes sense to ask GWT to compile H2 to run in the browser. H2 needs to write the database into local Files, which is something prohibited by browsers. Similar issue with Apache Shiro...

I'm sorry, WebFX isn't a magical tool that can transpile any JavaFX desktop application into a web app. Your app needs to be more compliant with the web ecosystem to get a chance. I think in your case JPro would be a better solution, because your "client" actually runs in a standard JVM on a server (and is therefore not constraint by the browser sandbox). Have you already tried JPro?

— Reply to this email directly, view it on GitHub https://github.com/webfx-project/webfx-cli/issues/9#issuecomment-1551484782, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHFAXTWLXLCVSLSAGKBK5ZDXGTM3XANCNFSM6AAAAAAYE67PLE . You are receiving this because you authored the thread.Message ID: @.***>

[mitvitaminen]

Hey Bruno,

I got a followup question: will we be able to import 3rd party libraries like mvvmfx and google guice or controlsfx? do u plan to adapt them maybe if not? How would you handle DB access, suppose the DB is mongoDB or some SQLDB, do you use JPA, I wonder how I get 3rd party libs into the webfx code,since the pom and webfx.xmls are managed by webfx. Should the server handle the DB via REST? Do you have code samples of running webfx sample applications? github would be nice. thanks for your time, kind regards Chris

Am Mi., 17. Mai 2023 um 17:15 Uhr schrieb Bruno Salmon < @.***>:

Thanks for keeping your interest in WebFX despite this first try! If you have followed the project, you may know that we are currently building an entreprise level app called Modality with WebFX. In the process, we are also building 2 important parts of the WebFX ecosystem: WebFX Stack https://github.com/webfx-project/webfx-stack and WebFX Extras https://github.com/webfx-project/webfx-extras. Their modules have not been published yet (still in incubation in private repos), but the READMEs provide some information (in particular the UI routing, Authn & Authz may interest you). It may take a year to finish all of this, but we will publish some video demos of Modality within a few months that will already demonstrate these features (and the potential of WebFX for enterprise web apps in general).

— Reply to this email directly, view it on GitHub https://github.com/webfx-project/webfx-cli/issues/9#issuecomment-1551587942, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHFAXTWJUBPGASCJKUASQFDXGTTSZANCNFSM6AAAAAAYE67PLE . You are receiving this because you authored the thread.Message ID: @.***>

[salmonb]

hi Chris,

No it's not possible to use libraries such as mvvmfx or controlsfx due to the WebFX limitations explained here. So the main 2 reasons are:

1) GWT can't compile any Java code (but something like 90% of Java), so libraries not designed for GWT will very likely use the 10% incompatible features (such as multi-threading, introspection, files, java 12+ features, etc...). That's why GWT has his own ecosystem.

2) WebFX doesn't support (yet) the whole JavaFX API (no JavaFX CSS, no TableView, no Charts, no 3D, etc...). That's the second reason why we can't use these libraries.

For libraries that have only problem 1), it's possible to make a WebFX version. That's the purpose of WebFX Libs. Eventually if they have problem 2) as well, we can just ignore the features not yet supported by WebFX and do a partial port. For example, this DemoFX WebFX library is a partial port of the original DemoFX without the 3D features.

To address problem 2), our strategy is more to build the WebFX Extras library that will provide simpler alternatives to the complex JavaFX components. For example, it will provide a DataGrid as an alternative to the TableView, and a simpler alternative Chart API. It should be good enough to start with, and we will see later if we can support the JavaFX complex components.

Regarding the communication with the server and a database, this is the main goal of WebFX Stack. And we prioritise Vert.x on server side (SpringBoot may arrive later) as this is the technological choice made for Modality. All this WebFX ecosystem is currently under construction at the same time as building Modality (which uses Postgres for the database by the way).

We think WebFX is more suitable to build new webapps in JavaFX than to port existing and already complex JavaFX applications. This may disappoint some developers, but if you see it primarily as what it is designed for, you get an amazing web framework, and it's cross-platform with native Android, iOS, Desktop, etc... The Modality team is very happy with WebFX, and like I said, we will publish some first video demos within a few months. So keep in touch!

[mitvitaminen]

HI Bruno, thanks for the detailed information, I will keep an eye out for you guys, since I think jpro does not scale well all executed on the server and considering their pricing of 99Euro per month for one server, well that is a lot...kind regards Chris

Am Di., 23. Mai 2023 um 13:46 Uhr schrieb Bruno Salmon < @.***>:

hi Chris,

No it's not possible to use libraries such as mvvmfx or controlsfx due to the WebFX limitations explained here https://docs.webfx.dev/#_limitations. So the main 2 reasons are:

1.

GWT can't compile any Java code (but something like 90% of Java), so libraries not designed for GWT will very likely use the 10% incompatible features (such as multi-threading, introspection, files, java 12+ features, etc...). That's why GWT has his own ecosystem. 2.

WebFX doesn't support (yet) the whole JavaFX API (no JavaFX CSS, no TableView, no Charts, no 3D, etc...). That's the second reason why we can't use these libraries.

For libraries that have only problem 1), it's possible to make a WebFX version. That's the purpose of WebFX Libs https://github.com/webfx-libs. Eventually if they have problem 2) as well, we can just ignore the features not yet supported by WebFX and do a partial port. For example, this DemoFX https://github.com/webfx-libs/webfx-lib-demofx WebFX library is a partial port of the original DemoFX https://github.com/chriswhocodes/DemoFX without the 3D features.

To address problem 2), our strategy is more to build the WebFX Extras https://github.com/webfx-project/webfx-extras library that will provide simpler alternatives to the complex JavaFX components. For example, it will provide a DataGrid as an alternative to the TableView, and a simpler alternative Chart API. It should be good enough to start with, and we will see later if we can support the JavaFX complex components.

Regarding the communication with the server and a database, this is the main goal of WebFX Stack https://github.com/webfx-project/webfx-stack. And we prioritise Vert.x https://vertx.io on server side (SpringBoot may arrive later) as this is the technological choice made for Modality https://github.com/modalityone/modality. All this WebFX ecosystem is currently under construction at the same time as building Modality (which uses Postgres for the database by the way).

We think WebFX is more suitable to build new webapps in JavaFX than to port existing and already complex JavaFX applications. This may disappoint some developers, but if you see it primarily as what it is designed for, you get an amazing web framework, and it's cross-platform with native Android, iOS, Desktop, etc... The Modality team is very happy with WebFX, and like I said, we will publish some first video demos within a few months. So keep in touch!

— Reply to this email directly, view it on GitHub https://github.com/webfx-project/webfx-cli/issues/9#issuecomment-1559129588, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHFAXTXV4HDQWLV7ETMSF33XHSPQRANCNFSM6AAAAAAYE67PLE . You are receiving this because you authored the thread.Message ID: @.***>

[mitvitaminen]

Hey Bruno, I am trying to get an IndexPage to work which I attached below. I get an error saying that IndexPage does not contain getStylesheets() even though it should be there, shall I file an Issue on the github page or is this an error of mine? In addition the Image is not showing, is there example code projects i can download, like the demos you show on your page but their sources maybe put them online as they can help to narrow down errors. Is there any other way to help you guys since I have been a Java developer for quite some time with 4 years business experience of course via pull request? Thanks for your time kind regards Chris

public class IndexPage extends GridPane {

public IndexPage() {

this.setAlignment(Pos.TOP_CENTER);

this.setHgap(10);

this.setVgap(10);

this.setPadding(new Insets(25, 25, 25, 25));

this.getStylesheets().add("css-client.css");

final Text t = new Text("Lorem Impsum");

t.getStyleClass().add("font2em");

this.add(t, 0, 0);

final ImageView logo = new ImageView("./img/img-sternschnuppe_logo.png");

this.getStyleClass().add("img-logo");

this.add(logo, 1, 0);

}

}

Am Di., 23. Mai 2023 um 13:51 Uhr schrieb Christian Rocholl < @.***>:

HI Bruno, thanks for the detailed information, I will keep an eye out for you guys, since I think jpro does not scale well all executed on the server and considering their pricing of 99Euro per month for one server, well that is a lot...kind regards Chris

Am Di., 23. Mai 2023 um 13:46 Uhr schrieb Bruno Salmon < @.***>:

hi Chris,

No it's not possible to use libraries such as mvvmfx or controlsfx due to the WebFX limitations explained here https://docs.webfx.dev/#_limitations. So the main 2 reasons are:

1.

GWT can't compile any Java code (but something like 90% of Java), so libraries not designed for GWT will very likely use the 10% incompatible features (such as multi-threading, introspection, files, java 12+ features, etc...). That's why GWT has his own ecosystem. 2.

WebFX doesn't support (yet) the whole JavaFX API (no JavaFX CSS, no TableView, no Charts, no 3D, etc...). That's the second reason why we can't use these libraries.

For libraries that have only problem 1), it's possible to make a WebFX version. That's the purpose of WebFX Libs https://github.com/webfx-libs. Eventually if they have problem 2) as well, we can just ignore the features not yet supported by WebFX and do a partial port. For example, this DemoFX https://github.com/webfx-libs/webfx-lib-demofx WebFX library is a partial port of the original DemoFX https://github.com/chriswhocodes/DemoFX without the 3D features.

To address problem 2), our strategy is more to build the WebFX Extras https://github.com/webfx-project/webfx-extras library that will provide simpler alternatives to the complex JavaFX components. For example, it will provide a DataGrid as an alternative to the TableView, and a simpler alternative Chart API. It should be good enough to start with, and we will see later if we can support the JavaFX complex components.

Regarding the communication with the server and a database, this is the main goal of WebFX Stack https://github.com/webfx-project/webfx-stack. And we prioritise Vert.x https://vertx.io on server side (SpringBoot may arrive later) as this is the technological choice made for Modality https://github.com/modalityone/modality. All this WebFX ecosystem is currently under construction at the same time as building Modality (which uses Postgres for the database by the way).

We think WebFX is more suitable to build new webapps in JavaFX than to port existing and already complex JavaFX applications. This may disappoint some developers, but if you see it primarily as what it is designed for, you get an amazing web framework, and it's cross-platform with native Android, iOS, Desktop, etc... The Modality team is very happy with WebFX, and like I said, we will publish some first video demos within a few months. So keep in touch!

— Reply to this email directly, view it on GitHub https://github.com/webfx-project/webfx-cli/issues/9#issuecomment-1559129588, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHFAXTXV4HDQWLV7ETMSF33XHSPQRANCNFSM6AAAAAAYE67PLE . You are receiving this because you authored the thread.Message ID: @.***>

[mitvitaminen]

additionally just cuz eclipse tells me so you guys should generate a

instead of just requires Am Mi., 7. Juni 2023 um 03:02 Uhr schrieb Christian Rocholl < ***@***.***>: > Hey Bruno, I am trying to get an IndexPage to work which I attached below. > I get an error saying that IndexPage does not contain getStylesheets() even > though it should be there, shall I file an Issue on the github page or is > this an error of mine? In addition the Image is not showing, is there > example code projects i can download, like the demos you show on your page > but their sources maybe put them online as they can help to narrow down > errors. Is there any other way to help you guys since I have been a Java > developer for quite some time with 4 years business experience of course > via pull request? Thanks for your time kind regards Chris > > public class IndexPage extends GridPane { > > > public IndexPage() { > > > this.setAlignment(Pos.TOP_CENTER); > > this.setHgap(10); > > this.setVgap(10); > > this.setPadding(new Insets(25, 25, 25, 25)); > > this.getStylesheets().add("css-client.css"); > > > final Text t = new Text("Lorem Impsum"); > > t.getStyleClass().add("font2em"); > > this.add(t, 0, 0); > > > final ImageView logo = new ImageView("./img/img-sternschnuppe_logo.png"); > > this.getStyleClass().add("img-logo"); > > this.add(logo, 1, 0); > > } > > > } > > Am Di., 23. Mai 2023 um 13:51 Uhr schrieb Christian Rocholl < > ***@***.***>: > >> HI Bruno, >> thanks for the detailed information, I will keep an eye out for you guys, >> since I think jpro does not scale well all executed on the server and >> considering their pricing of 99Euro per month for one server, well that is >> a lot...kind regards Chris >> >> Am Di., 23. Mai 2023 um 13:46 Uhr schrieb Bruno Salmon < >> ***@***.***>: >> >>> hi Chris, >>> >>> No it's not possible to use libraries such as mvvmfx or controlsfx due >>> to the WebFX limitations explained here >>> . So the main 2 reasons are: >>> >>> 1. >>> >>> GWT can't compile any Java code (but something like 90% of Java), so >>> libraries not designed for GWT will very likely use the 10% incompatible >>> features (such as multi-threading, introspection, files, java 12+ features, >>> etc...). That's why GWT has his own ecosystem. >>> 2. >>> >>> WebFX doesn't support (yet) the whole JavaFX API (no JavaFX CSS, no >>> TableView, no Charts, no 3D, etc...). That's the second reason why we can't >>> use these libraries. >>> >>> For libraries that have only problem 1), it's possible to make a WebFX >>> version. That's the purpose of WebFX Libs >>> . Eventually if they have problem 2) as >>> well, we can just ignore the features not yet supported by WebFX and do a >>> partial port. For example, this DemoFX >>> WebFX library is a >>> partial port of the original DemoFX >>> without the 3D features. >>> >>> To address problem 2), our strategy is more to build the WebFX Extras >>> library that will >>> provide simpler alternatives to the complex JavaFX components. For example, >>> it will provide a DataGrid as an alternative to the TableView, and a >>> simpler alternative Chart API. It should be good enough to start with, and >>> we will see later if we can support the JavaFX complex components. >>> >>> Regarding the communication with the server and a database, this is the >>> main goal of WebFX Stack . >>> And we prioritise Vert.x on server side (SpringBoot >>> may arrive later) as this is the technological choice made for Modality >>> . All this WebFX ecosystem is >>> currently under construction at the same time as building Modality (which >>> uses Postgres for the database by the way). >>> >>> We think WebFX is more suitable to build new webapps in JavaFX than to >>> port existing and already complex JavaFX applications. This may disappoint >>> some developers, but if you see it primarily as what it is designed for, >>> you get an amazing web framework, and it's cross-platform with native >>> Android, iOS, Desktop, etc... The Modality team is very happy with WebFX, >>> and like I said, we will publish some first video demos within a few >>> months. So keep in touch! >>> >>> — >>> Reply to this email directly, view it on GitHub >>> , >>> or unsubscribe >>> >>> . >>> You are receiving this because you authored the thread.Message ID: >>> ***@***.***> >>> >>

[salmonb]

hi Chris,

In general, it's good to develop (write, run & debug) the OpenJFX version of your app first. The way to do that in your IDE is explained in the docs.

So try to make your app run with the OpenJFX runtime first in your IDE. There is no chance to get a successful GWT build if it doesn't build with OpenJFX first. This first step should allow you to determine if the problem is with your code or with WebFX.

In your case, you should see that the problem is with your code, because getStylesheets() is a method of the Scene class, not of the Node class. I think you should move this line of code into your main JavaFX application class where you create the scene.

Once you manage to make your app work with OpenJFX, you will still have some additional steps to make it work with WebFX. For example, when loading resources (such as images), you need to use the WebFX Resource class (that will translate the resource path into an url for the browser), and write something like:

final ImageView logo = new ImageView(Resource.toUrl("/img/img-sternschnuppe_logo.png", getClass());

To import this WebFX class in your code, first use the fully qualified name of the class like this:

final ImageView logo = new ImageView(dev.webfx.platform.resource.Resource.toUrl("/img/img-sternschnuppe_logo.png", getClass());

and then run webfx update (the CLI should detect this new usage and automatically add the corresponding WebFX module to your build chain). Once done, you can replace the fully qualified name with an import (I guess your IDE will propose you to do it) and your final code will be simplified like the first line of code listed above.

Then, if you are using CSS, there will be some additional steps, because WebFX doesn't emulate JavaFX CSS in the browser. This is on purpose, because doing so would make your app much bigger and slower, a shame while the browser already has a very optimised built-in CSS engine! So the WebFX approach for apps using CSS is not to emulate the JavaFX CSS but rather to have 2 versions of the CSS: one for JavaFX and one for HTML. A bit more work for the developer, but a much more optimised app in the end.

To achieve this, you need to create a separate generic css interface module (this interface module will be actually empty but this is the one you will import in your application), and then implement it in 2 versions: a -openjfx submodule (containing the JavaFX CSS file) and -web submodule (containing the equivalent HTML CSS file). You can use the webfx create module command to create each module. The interface and implementing modules require some directives in webfx.xml to make this work. You can find an example of this in our FX2048 demo.

Let me know if you need more help.