Yes, but XMLHttpRequest is a thin wrapper that can easily be replaced with JsInterop. (it also uses a Timer, which uses JSNI, that can also easily be replaced with JsInterop)
On Saturday, February 6, 2016 at 6:59:33 PM UTC+1, Alain wrote: > > Does not it rely on xmlhttp request which uses jsni ? > On 6 Feb 2016 18:55, "Thomas Broyer" <[email protected]> wrote: > >> There's no reason it couldn't: does not use generator nor JSNI. >> >> On Saturday, February 6, 2016 at 11:08:15 AM UTC+1, DavidN wrote: >>> >>> Will the RequestBuilder API remain ? >>> >>> >>> On Fri, Feb 5, 2016 at 9:36 PM Ed <[email protected]> wrote: >>> >>>> RestyGWT is one of the options. Another less mentioned is the low level >>>> RequestBuilder. We moved to RB due to the large number of fields we are >>>> managing (400+) and use json on the client to consume the requests. >>>> >>>> Ed >>>> >>>> On Fri, Feb 5, 2016 at 5:44 AM, Vassilis Virvilis <[email protected]> >>>> wrote: >>>> >>>>> I have successfully ported a medium API (~30 methods) from GWT-RPC to >>>>> Resty-GWT. While everybody's case is unique it went surprisingly well for >>>>> me (as far as transitions go). >>>>> >>>>> 1) The big advantage is that although you can use RestyGWT with a >>>>> procedural SOAP logic (like GWT-RPC) you can start familiarize yourself >>>>> with the new API design of the Restful tomorrow word. >>>>> >>>>> 2) Another advantage for me was that I had already a WS stack (CXF) >>>>> and thus with GWT-RPC I was either reimplementing my CXF services or I >>>>> was >>>>> proxying them. >>>>> >>>>> 3) By ditching GWT-RPC I was able to free myself from server side code. >>>>> >>>>> 4) It is now easier to work with standard json and json inspection >>>>> tools like console.log(object_received) and with browser's network >>>>> inspection tools >>>>> >>>>> 5) RestyGWT has a async interface in order to keep your familiar >>>>> GWT-RPC handlers so the changes in the code are minimal. What takes more >>>>> work is to ensure that all your object's are transmitted correctly over >>>>> the >>>>> wire. This is not walk in the park but for simple objects it just works. >>>>> For more complex cases you may need to implement a Provider or something. >>>>> >>>>> 6) I don't know about your special @annotations that somehow remove >>>>> the need to specify interface + async_interface but for me this is a >>>>> major >>>>> plus. The client code does not need to link to server definitions and for >>>>> me API is something that changes with great difficulty and rarely. So >>>>> wher >>>>> API breaks I am editing both files - I don't mind. >>>>> >>>>> Vassilis >>>>> >>>>> >>>>> On Fri, Feb 5, 2016 at 4:16 AM, <[email protected]> wrote: >>>>> >>>>>> I understand that the future of GWT RPC does not seem bright in 3.0+ >>>>>> but I want to express my opinion that this is a HUGE mistake. GWT RPC is >>>>>> one of the most important things in GWT as it truly ties things together >>>>>> in >>>>>> large apps. Sure, it its raw form it is a bit cumbersome to use but it >>>>>> enables true code reuse with no extra coding. This is what sets GWT >>>>>> apart >>>>>> from the run-of-the-mill frameworks out there. Creating custom requests >>>>>> and >>>>>> responses is not maintainable and scalable in a large app that depends >>>>>> on >>>>>> extensibility and polymorphism. Ability to communicate almost any Java >>>>>> object graph without having to specifically annotate or declare >>>>>> anything, >>>>>> while preserving singletons is a huge advantage. >>>>>> >>>>>> Sure, it lacks a lot of things. We used it with out proprietary >>>>>> wrapper framework in a way that allows us to simply annotate sever-side >>>>>> methods we want to expose to the client and everything else is >>>>>> automagically handled - the client gains the visibility into relevant >>>>>> server classes and methods with same signatures other than getting >>>>>> results >>>>>> asynchronously. One can pass results of some method call as an argument >>>>>> of >>>>>> another all without leaving the sever and without having to wire >>>>>> boilerplate/weird code.For example, if we had the following code on the >>>>>> server >>>>>> >>>>>> public class Foo { >>>>>> public static Bar getBar() { >>>>>> return new Bar(); >>>>>> } >>>>>> public static String someText() { >>>>>> return "Blah: " + System.currentTimeMillis(); >>>>>> } >>>>>> } >>>>>> public class Bar { >>>>>> public String twice(String text) { >>>>>> return text + text; >>>>>> } >>>>>> } >>>>>> >>>>>> >>>>>> >>>>>> .... with our annotations on the server (not shown) the following >>>>>> client code would be possible: >>>>>> >>>>>> Foo.getBar().twice(Foo.someText(), new AsyncCallback<String>() { >>>>>> ... >>>>>> public void onSuccess(String result) { >>>>>> ... >>>>>> } >>>>>> } >>>>>> >>>>>> ... no need for creating server + async interfaces, etc. >>>>>> >>>>>> With every other alternative we lose on simplicity and ability to >>>>>> communicate. All others require us to create more client-server >>>>>> communication code which we have been able to avoid. >>>>>> >>>>>> Needless to say, we'd be stuck in pre-3.0 land as we have a large >>>>>> code investment in GWT RPC - we could not accept losing it... but we do >>>>>> want to go to the newest GWT at any time. It would be greatly >>>>>> disappointing >>>>>> if we couldn't do this. >>>>>> >>>>>> I do not see the advantages of losing RPC. It does what it does >>>>>> better than anything else out there and is irreplaceable. >>>>>> >>>>>> Please do not get rid of it. Enhance it. It is what makes GWT better >>>>>> than the rest. It is what, together with the rest, allows seamless and >>>>>> uniform language use across the client and the server. >>>>>> >>>>>> -- >>>>>> 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 [email protected]. >>>>>> To post to this group, send email to >>>>>> [email protected]. >>>>>> Visit this group at >>>>>> https://groups.google.com/group/google-web-toolkit. >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Vassilis Virvilis >>>>> >>>>> -- >>>>> 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 [email protected]. >>>>> To post to this group, send email to >>>>> [email protected]. >>>>> Visit this group at https://groups.google.com/group/google-web-toolkit >>>>> . >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>>> 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 [email protected]. >>>> To post to this group, send email to >>>> [email protected]. >>>> Visit this group at https://groups.google.com/group/google-web-toolkit. >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >> 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 [email protected]. >> To post to this group, send email to [email protected]. >> Visit this group at https://groups.google.com/group/google-web-toolkit. >> For more options, visit https://groups.google.com/d/optout. >> > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/google-web-toolkit. For more options, visit https://groups.google.com/d/optout.
