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:
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" <t.broyer@gmail.com> 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 <ej197us@gmail.com> 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 <vasvir2@gmail.com> wrote: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 tools3) By ditching GWT-RPC I was able to free myself from server side code.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.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.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, <gwtarplayer@gmail.com> 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 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:xt (), 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 google-web-toolkit+unsubscribe@googlegroups.com .
To post to this group, send email to google-web-toolkit@googlegroups.com .
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 google-web-toolkit+unsubscribe@googlegroups.com .
To post to this group, send email to google-web-toolkit@googlegroups.com .
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 google-web-toolkit+unsubscribe@googlegroups.com .
To post to this group, send email to google-web-toolkit@googlegroups.com .
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 google-web-toolkit+unsubscribe@googlegroups.com .
To post to this group, send email to google-web-toolkit@googlegroups.com .
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 google-web-toolkit+unsubscribe@googlegroups.com.
To post to this group, send email to google-web-toolkit@googlegroups.com.
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
No comments:
Post a Comment