Thanks for the info. Yeah, I've got all the biz logic broken out from
the protocol, as I support form post and json get's using the same api
(essentially...) It's interesting that the wireformat is json. I was
sorta hoping it was some super tight binary format that would tempt me
to switch (I'm not sure it would, latency is so much worse than
throughput). Turning on gzip compression on the http server basically
makes my json into binary anyway though...
I'm sticking with json until I no longer need access by non-gwt
clients. Those overlay types mentioned previously are -very
tempting-. I need to look into that, as overlaying a class on my raw
json from requestbuilder would nice -- especially if I don't have to
wear out letters on my keyboard typing isNumber().doubleValue() ever
again (note to self: write a function)
On Oct 29, 3:20 pm, "Ian Petersen" <[EMAIL PROTECTED]> wrote:
> On Wed, Oct 29, 2008 at 10:37 AM, Brian <[EMAIL PROTECTED]> wrote:
> > Sounds good.
> > Is the gwt-rpc format described, so I could write a non-gwt app (say,
> > a mac desktop gadget) that hits my server using the same api as the
> > gwt-rpc browser app? Note, I don't actually care right now what the
> > format is, just that the protocol is described, and is easy to impl in
> > a non-gwt-rpc-browser app (like it is with json ;-)
>
> I think Jason and Walden gave pretty good answers, but I thought I'd
> give a little more detail.
>
> The GWT RPC format is intentionally opaque JSON. This makes it
> somewhere between difficult and impossible to add a non-GWT agent to
> the RPC discussion. There isn't really a nice work-around for
> creating a non-Java server-side implementation but, because your
> RemoteServiceServlet implementation just has to implement your
> synchronous RPC interface, it's quite possible for non-GWT clients to
> talk to the same server-side business logic, just without using the
> RPC protocol.
>
> The easiest way to implement RPC on the server is like this:
>
> public interface HelloWorld extends RemoteService {
>
> String sayHi(String name);
>
> }
>
> public class HelloWorldServlet extends RemoteServiceServlet implements
> HelloWorld {
>
> public String sayHi(String name) {
> return "Hello, " + name;
> }
>
> }
>
> In a GWT client, you'd use it like this:
>
> // you need to maintain an Async interface in parallel to the service
> definition
> public interface HelloWorldAsync {
>
> void sayHi(String name, AsyncCallback<String> callback);
>
> }
>
> HelloWorldAsync service = (HelloWorldAsync) GWT.create(HelloWorld.class);
>
> service.sayHi(new AsyncCallback<String>() {
>
> public void onFailure(Throwable caught) {
> // handle server-side errors and networking errors
> }
>
> public void onSuccess(String response) {
> Window.alert("Server says: " + response);
> }
>
> });
>
> So, from a GWT perspective, it's _really_ easy. The point I'm trying
> to make here, though, is that the server side is just an
> implementation of an interface. It's possible (using the class named
> RPC) to implement that interface on one class and answer HTTP POST
> request in a different class (the above example does everything in one
> class by subclassing RemoteServiceServlet). Separating the business
> logic from the HTTP request-handling means that you can re-use the
> business logic to support non-GWT clients in whatever fashion you
> like, including standard Java RMI, and RESTful webservices.
>
> On Wed, Oct 29, 2008 at 10:45 AM, Brian <[EMAIL PROTECTED]> wrote:
> > I care heavily about the wireformat of my requests. Maybe that's
> > because I have bugs in my json api from time to time, but it's very
> > handy to fire up ethereal/wireshark and check what's happening on the
> > wire. But I hear ya, it'd "be nice" if I didn't have to care, I just
> > do.
> > Is the wireformat plaintext? Is it published?
> > Thanks everone for the info. Guess I got my answers, and I should
> > start hitting the api docs on gwt-rpc if I start going down this road.
>
> The wire format is plain text. It's actually JSON. It's just
> unreadable JSON because the assumption is that both the producing and
> consuming code is auto-generated and can make all kinds of assumptions
> about the structure of the text.
>
> I've explained the wire format in copious detail in previous posts to
> either this list or the GWT-Contributors list. If you're interested
> in the gory details, you could search for those old posts. Just be
> aware that I was explaining the format as it was used in GWT 1.4. The
> RPC guts have changed very slightly since then to support a few
> features in custom field serializers. Also, I think GWT 1.5 has
> redefined or stopped using some of the flags that were available in
> the old format. In other words, the spirit of the format is still the
> same, but there might be some differences in the details now.
>
> Ian
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to Google-Web-Toolkit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/Google-Web-Toolkit?hl=en
-~----------~----~----~----~------~----~------~--~---
