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.
