I am new to GWT and am able to work around with GWT RPC but have problem in understanding how the control flow takes place internally. How it gets translated to AJAX?
Can we use new() instead of GWT.create(someService.class) to make an RPC call?
Why does Google not just use Async version instead of creating 2 interfaces?
What happens internally when we use
TaskService Async = GWT.create(TaskService.class);
I have read that it chooses the browser specific hashname.js file but am not understanding the complete control flow. Also How is the Callback Object used.
Can someone explain the control flow by pointing out the essentials?
UPDATE : #Thomas Broyer, Everything I understood... Just confirming that in case GWT.create() there is a .rpc file in the client side which helps in the deferred(late/runtime) binding. Is that correct?
GWT.create() will in this case call a GWT generator; it'll generate a class implementing the Async interface (and that's why you only have to declare an interface and you never implement it yourself).
See RPC Plumbing Diagram.
Using a generator (or selecting a specific implementation, but in the case of GWT-RPC, a generator is used) is called deferred binding.
So, no, you cannot use new.
As to why there are 2 interfaces, this is so that GWT can check that your server-side code (synchronous) is consistent with your client-side code (async). The reason you call GWT.create on the synchronous interface and it returns an implementation of the async one is legacy. I bet they wouldn't do it that way, were they to re-implement GWT-RPC from scratch.
The generated class will be responsible of serializing the call (method name and arguments) and make an AJAX request (using a RequestBuilder); and then deserialize the response (either of the type declared, or an exception)
Because calls are asynchronous, the callback is used to, well, call your code back when the server responds, after deserialization takes place (so either calling onSuccess with the decoded object, or onFailure with the decoded exception).
See Getting Used to Asynchronous Calls
Related
I'm working on a GWT project which calls the server via RPC. A typical RPC calls the Server and passes some information and then recieves the answer as an ArrayList.Now we noticed that with a growing database we should use pagination to not overcharge the client with to many objects.
The problem is that there are at the moment many existing methods which are using RPC and each of them would must be modified to provide the necessary information for pagination (Count of Objects,Current Position ) . If i would change every method i would have to edit the Synchronous Interface,the Asynchronous Interface, and the Server and Client class which are using/implementing them.
I tried to create a generic Wrapper class, but i couldn't make it suitable for out project,because each object must be casted back in the original type. Is there a way with less effort to provide pagination without editing many methods?
Background:
I've written an LWP::Protocol "implementor" for HTTP(S) based on AnyEvent::HTTP. (i.e: it implements both HTTP and HTTPS).
It's different than LWP::Protocol::AnyEvent::http or Coro::LWP in that it doesn't BLOCK on $protocol->request. I've implemented most of the same hacks for select(), name-resolution etc that Coro::LWP does, but making better use of AnyEvent.
The HTTP response returned by $protocol->request() is 230 - Pending Completion of Request for now but I'm open to better ways to convey that it isn't a completed request.
I've also written a subclass of HTTP::Response which forces BLOCKING on the standard "consumer" methods if they attempt to use parts of the response before it's complete; it also adds methods for working nicely with internal/provided AnyEvent::CondVar so that you can fire lots of requests off at once, as well as do other stuff with AnyEvent. (I've also overridden all of LWP::UserAgent's post-send_request() logic to defer it until the real request completion).
Problem:
I'm currently doing a hack were I have my LWP::UserAgent subclass "upgrade" the URL scheme by appending '_async' for async requests, and I've got the LWP::Protocol subclass being an "implementor" for schemes matching /^https?_async$/
Question:
How can I get my LWP::UserAgent subclass to choose my (more asynchronous) HTTP & HTTPS protocol "implementors" instead of others installed on the system? (i.e: when the LWP::UserAgent subclass calls LWP::Protocol::create).
Can I force selection of my "implementors"? Or is there a more natural way to do this?
You need to call implementor in close proximity to your send_request call:
LWP::Protocol::implementor('http', 'your::module::name');
See source of http://search.cpan.org/~gaas/LWP-Protocol-http10-6.03/lib/LWP/Protocol/http10.pm to understand what you need to implement to replace the HTTP protocol handler
How do I send POST/PUT/DELETE calls to a rest source using Atmosphere 1.1.0+ in a conventional RPC manner? (You are guessing right, I want to employ pub/sub and RPC style in my project)
serverside: register a #Path (e.g. /member), mark with #POST/#PUT/#DELETE, process the method body and return the value. Seems straight forward. Even with JSON en-/decoding.
clientside: How would you kick a POST request with the wasync library? All atmosphere examples use "GET" and recommended to use GET only. Why is that?
RequestBuilder request = client.newRequestBuilder().method(Request.METHOD.GET).uri("/member")
Can one expect this synchronous server response when invoking the fire method? e.g.
Future future = socket.fire(myMemberObject)
Thank you for hints and comments on this approach (also thoights on pairing RPC and PubSub are welcome).
wAsync is using POST once the connection is established. wAsync is asynchronous by nature so you need to use Latch if you want to make it blocking, or use AsyncHttpClient with Future.
Does anyone know if it is possible to write to the response stream in OpenRasta rather than returning an object as a response resource? Alternatively, am I able to implement an HTTP handler but still leverage OpenRasta's URL rewriting?
Thanks
Chris
You can always keep an http handler on the side to do specialized things, but that ties you to asp.net and will prevent your code from being portable on other hosts. If that's something you're ok with, any handler that's registered for a specific route will get executed before openrasta on asp.net.
that said, codecs are the ones writing to the response stream, so provided you have a custom IMediaTypeWriter you can write the resource instance on a stream whichever way you want.
Say for example that you returned an IEnumerable from your handler, as those get deferred executed, you can just start the enumeration of those in your custom codec without any problem.
what is the need to create Async and Sync interface in client package and its impl class in Server package when need to impelement RPC in GWT. What is the need to create Sync as well as Async interface in GWT for successful RPC.
In a nutshell: Async is needed for client side, Sync is needed for server side.
All RPC (XmlHttpRequest) calls in Javascript are asynchronous - when network call is finished, your code is called with result.
So on client side with GWT RPC you must provide an Async interface (and implementation of it) in order to be called when results are available.
You must also provide related Sync interface which is implemented on server side.
There is a contract on how Async and Sync interface must be written: http://code.google.com/webtoolkit/doc/latest/tutorial/RPC.html
well I assume that you know that any JS in browser is kind of synchronous event driven.
To responce to the RPC you need a callback.
So when writing Java code you need to pass the callback object to a call.
but the server side is a simple method call with return type that should match the parameter of the callback. Right?
So here you get 2 interfaces that all together give you full type safety at compile time. and allows it all work smooth as it does.