Dissenting opinion, mostly for the sake of discussion (though I'll admit to being an RPC fanboy too):
This came up in discussion in ##gwt today, from the other perspective - the stockwatcher app uses JsonpRequestBuilder, which is incompatible with JsType without some seriously fugly casts (as far as we could figure out), and hasn't been updated since GWT 1.6 was new. I might almost take the other perspective - at least RPC (with or without @JsType annotations so the loaded objects could be used in external JS) will at least work in modernized gwt, but JsonpRequestBuilder requires some hoops to jump through to make sense. Anything talking about Element or other JSOs is likely to become confusing as well in the very near future, as JSO.cast() is bound to JSO subtypes, so you need to cast first to Object and then to the appropriate JsType. JsArray<JavaScriptObject> results;//from JsonpRequestBuilder callback MyJsType instance = (MyJsType) (Object) results.get(0);//or a JSNI 'cast', which also won't exist in GWT 3 In contrast (donning my asbestos suit...) RPC still works as-is today and doesn't have any serious GWT-compatible future-proof competition in terms of sending graphs of plain Java objects. There appears to be the risk that GWT 3 may not support the so-called "violator pattern", but until we have the ability to actually run the compiler, there is no guarantee of that - at worst, they can be @JsTyped so the field names won't be renamed... I think. A future APT-built set of serializers could walk getters/setters and provide the same graph serializer that RPC gets us today (and possibly even with less terrible errors...). If we get rid of RPC docs and samples because Generators are on the way out, but replace with RequestBuilder or JsonpRequestBuilder, we're just trading one "it probably won't work in 3" for another. Plus, the same logic says references to Widgets/UiBinder/etc should be removed as well. If it's just for the "there is another way to do it", why be opinionated? I could see a disambiguation page to discuss the pros/cons (and relative future-proofness, or lack thereof), but outright removing seems... harsh. On the other hand, if we have tools (i.e. outside of gwt-user) that work with only jsinterop and APT, my points make a lot less sense, but I don't think we're there yet. -- As replacement goes, I like AutoBeans for nearly the same reason as RPC - the server-side de/serialization is consistent, predictable, and supports Java conventions and apis. Alas, it has the same problems of being rooted in the past - JsoSplittable, generators. You can make JAX-RS methods work, but the surprise gotchas (server supports polymorphism but client doesn't? No easy primitive wrapping or enums? No Java collections, and odd behaviors in array instanceof? etc) seem like they would require both that the doc be opinionated on which server serialization tool is used, and provide the laundry list of things to watch out for. Personally I'd like to see a plan around a GWT 3 capable tool that addresses the entire experience before talking about removing RPC - and then take JSOs, JSONObject, AutoBean, RequestFactory, etc all out at the same time. On Thursday, April 20, 2017 at 1:33:48 PM UTC-5, Thomas Broyer wrote: > > Should we start thinking about removing GWT-RPC from our sample app? (and > probably tutorial on the web site) > What would we replace it with though? I'd suggest plain old HTTP with JSON > and JsInterop; but what about the server? Using HTTP POST with > manually-encoded application/x-www-form-urlencoded data and org.json (or > AutoBean?) to encode the response as JSON? > -- You received this message because you are subscribed to the Google Groups "GWT Contributors" group. To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/cd5dc7ed-fbe9-4944-9b94-a554093295fc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
