search

cincheo / jsweet-quickstart

A template project to start with JSweet Java to TypeScript transpiler.
Apache License 2.0
17 stars 9 forks source link

js in target/ directory? #3

Closed buko closed 5 years ago

buko commented 5 years ago

Been playing around with this... first let me say JSweet is very cool stuff! Also love the Eclipse Plugin. (Though you should mention that you have a kick-ass Eclipse plugin more prominently on the home page. Didn't discover this until later.)

I notice the quickstart 'webapp' refers to javascript in the 'target' directory. We don't really want that do we? Does it make sense to have an additional maven task to copy all the generated javascript files into a 'webapp/js' directory?

The 'webapp' is also a bit confusing because it's not actually a webapp that produces a war. Ideally wouldn't we want the webapp to be something we can actually deploy and run in production?

One thing that's not completely clear is how the generated javascript would communicate back to the webapp. I guess this may be beyond the scope of a simple quickstart but I'd love to see an example of the code actually sending and receiving data back to a real JAXRS application. Like instead of just printing hello world the generated javascript would send an Ajax request back to a '/greeting' service and update the page when the user prints a button. This would be a much more useful, "real world" quickstart. What do you think?

I'm also particularly curious about the 'Shared Data Layer' mentioned in (http://www.jsweet.org/10-reasons-to-use-jsweet/) -- Reason 6: Java as a Multi-tiers Language. Is there an example of this somewhere? Would love to see a real-world example of the javascript sending and receiving json back to the java web services.

lgrignon commented 5 years ago

Hello @buko, Thanks for your nice feedback! Yes, Eclipse plugin is cool, but not up to date anymore. It would be nice to upgrade it to 2.2.0 I personally use JSweet maven plugin's watch task and it is really simple to use.

It would definitely be better to copy generated JS files into a webapp/js directory. I agree that maybe we could rename webapp folder to something like www. Would you want to PR those 2 adjustments?

If you are interested on how to share a common model between a Java server and a JSweet client, please take a look at: https://github.com/lgrignon/jsweet-jaxrs-server-example https://github.com/lgrignon/jsweet-cordova-ionic-example Those projects haven't any comprehensive documentation but it is a good start to understand.

You can see that they share a common model: https://github.com/lgrignon/jsweet-cordova-ionic-example/tree/master/src/main/java/org/jsweet/ionicexercise/client/model https://github.com/lgrignon/jsweet-jaxrs-server-example/tree/master/src/main/java/org/jsweet/ionicexercise/client/model

Code isn't actually shared in those examples, but it would be possible by having all of this code into one project, or by using a candy project to hold & share those model classes.

I hope this answered your questions. Please feel free to ask any question and submit any contribution, I would be glad to review.

buko commented 5 years ago

That cordova-ionic example is exactly what I was looking for: it shows clearly how to create javascript code and have it communicate with a JAXRS API. I'm not sure why you say the data model isn't shared. It looks like both the client code (https://github.com/lgrignon/jsweet-jaxrs-server-example/blob/master/src/main/java/org/jsweet/ionicexercise/client/app/CoffeeShopController.java) and the server endpoints (https://github.com/lgrignon/jsweet-jaxrs-server-example/blob/master/src/main/java/org/jsweet/ionicexercise/webapi/CoffeeShopApi.java) are sharing the same CoffeeShopDto classes. For us, this was a major incentive for potentially using something like jsweet: the possibility for massive reuse. We've got a large, complicated model and it's a huge pain point. Thanks for the pointer. Starting here I'll continue digging.