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.
