Re: New Presentation about Modern GWT Webapp Development

Hi Thomas,

Surely we need to do the platform specific stuffs somewhere... but not in my programming language as keywords --> "the abstraction level" 🤔

Using platform specific super-source for GWT is fine but I don't have that in Java and I don't want to have that in Java. For me you have following level of integration:

- Programming language (like Java, Kotlin, ...)

- Frameworks and libraries (like GWT, Spring Framework, ...)

- Build tools (like Maven, Gradle, ...)

Platform specific stuffs should not go to programming language but they can go to frameworks or build tools, so that the programming language can be stable for a long time.

I'm afraid that the programming language will become "unstable" if you add something like "expect/actual"? But maybe I'm just too carefully 😀The new generation of programming language will break everything faster 😂

Cheers,

Lofi

t.br...@gmail.com schrieb am Mittwoch, 16. September 2020 um 19:49:33 UTC+2:

On Wednesday, September 16, 2020 at 6:49:36 PM UTC+2, lofid...@gmail.com wrote:

Hi Thomas,

... actually I feel that doing platform specific stuffs in my code it's not the way.

It is comparable to GWT vs. jsweet. In GWT you have everything in Java semantic. In jsweet you actually have everything in Java but with JavaScript semantic. jsweet is for me still better than JavaScript 😉but I lost the Java semantic.

Putting platform specific stuffs in the code mixes the separation of concern, IMHO...

Last time I wrote super-source was… last week!

Using @JsType(isNative=true,namespace=GLOBAL,name="Object") classes to talk to ProseMirror, translating between some XML and those JS objects (context: https://twitter.com/tbroyer/status/1303647011279966208).

In this case, this is purely client code, but I didn't want to use a GWTTestCase to test my XML↔Objects transforms, so I wrote the test to run in the JVM (and also made it work in a GWTTestCase, to make sure it does indeed work, but it's a lot slower).

Now how would you handle arrays? Well, I just use a @JsType(isNative=true,namespace=GLOBAL,name="Array") with a few @JsOverlay methods delegating to Js.asArrayLike(this)… in the super-source, with a simplement implementation wrapping an ArrayList for the JVM.

And how to compare the object trees in the tests? I cannot use things like isEqualToComparingFieldByFieldRecursively, and I didn't want to build something equivalent just for tests, so I just serialize them to JSON, using JSON.stringify() in super-source for GWT (not directly JSON.stringify() though, as object fields are not in a predictable order, but more https://www.rfc-editor.org/rfc/rfc8785.html#name-ecmascript-sample-canonical, which relies on JSON.stringify for "primitive" values), and GSON (that we already have around in GWT) in the JVM.

Of course I could have built things differently, with abstract factories so I could inject a GWT-specific or a JVM-specific one, and I actually went that route initially, but honestly, just so I can use a different List subclass within tests?

(granted, the previous time I wrote super source, besides GWT's own javaemul, was a long time ago :D but I never really shared a lot of code between server and client anyway: besides that rich text editor, those 10 other subproject dependencies are actually only there for enums and some constants, and of course one of them is about RequestFactory interfaces)

--
You received this message because you are subscribed to the Google Groups "GWT Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit/c99e20f7-84d5-4e07-9afe-7e96ea8d8fa1n%40googlegroups.com.