JSON4Brwsr
From APIDesign
(→org.apidesign.html.json) |
(→org.apidesign.html.json) |
||
| Line 13: | Line 13: | ||
The above [[ClientAPI]] is accompanied with associated [[ProviderAPI]] and [[TCK]]: [http://bits.netbeans.org/html+java/1.2/org/netbeans/html/json/spi/package-summary.html HTML JSON SPI] | The above [[ClientAPI]] is accompanied with associated [[ProviderAPI]] and [[TCK]]: [http://bits.netbeans.org/html+java/1.2/org/netbeans/html/json/spi/package-summary.html HTML JSON SPI] | ||
| - | Depending on the execution technology (e.g. [[Bck2Brwsr]] vs. [[HotSpot]] vs. for example [[ | + | Depending on the execution technology (e.g. [[Bck2Brwsr]] vs. [[HotSpot]] vs. for example [[TeaVM]] rendering technology ([[Knockout.js]] or [[Angular.js]], [[Jersey]], etc.) and [[JSON]] persistence technology (e.g. native [[JavaScript]] objects vs. ''netscape.JSObject'' vs. [[Java]] wrapper like Jackson) one selects the right provider. |
As a result we can use the same [[API]] and execute it in different contexts (real browser, [[FXBrwsr]] or server). [[Java]] can once again guarantee its original [[WORA]] promise. | As a result we can use the same [[API]] and execute it in different contexts (real browser, [[FXBrwsr]] or server). [[Java]] can once again guarantee its original [[WORA]] promise. | ||
Revision as of 06:42, 2 September 2015
JSON is the standard API for persisting objects in current browsers. In case Java wants to get Bck2Brwsr it needs to play well with JSON. You may think there has been too many APIs to access JSON from Java created already -- one of them must fit the needs of Bck2Brwsr (and FXBrwsr). Well, it does not. The reason is that for all the previous attempts the assumption was that Java is the base and JSON is built on top of its runtime. In case of the Bck2Brwsr project the situation is up-side-down. JavaScript (and thus also JSON) is naturally supported and Java lives above it.
net.java.html.json
Can the Java to JSON mapping get any simpler than net.java.html.json package?
I doubt. With the help of AnnotationProcessors we remove the need to type boiler plate code. Don't bother with getters and setters, don't bother with fields. Just use the @Property annotation and the rest will be generated for you. When you need to talk to server use @OnReceive annotation and you get the result. Type-safe. Reflection-less. Effective.
As the Twitter example shows, with the Java code may in fact the smaller than the same JavaScript one.
org.apidesign.html.json
The above ClientAPI is accompanied with associated ProviderAPI and TCK: HTML JSON SPI
Depending on the execution technology (e.g. Bck2Brwsr vs. HotSpot vs. for example TeaVM rendering technology (Knockout.js or Angular.js, Jersey, etc.) and JSON persistence technology (e.g. native JavaScript objects vs. netscape.JSObject vs. Java wrapper like Jackson) one selects the right provider.
As a result we can use the same API and execute it in different contexts (real browser, FXBrwsr or server). Java can once again guarantee its original WORA promise.
Write Your Own Provider
- Get the sources and check the implementation in ko-fx and ko-bck2brwsr modules.
- Implement your own context provider
- Guarantee your Knockout.js binding (if you are attempting to do Knockout.js binding) is correct by running the TCK: http://hudson.apidesign.org/hudson/job/bck2brwsr-net.java.html.json/lastSuccessfulBuild/artifact/json-tck/target/site/apidocs/org/apidesign/html/json/tck/KnockoutTCK.html
In case of questions, ask on our mailing list bck2brwsr (at) apidesign.org
Follow
