a way to make a service call "protocol agnostic" via defered binding?

[Elhanan]

is there a way for to define an interface and 2 implementations of it
(one uses RPC, the other JSON) to call servlets or services on the
server? and using gwt defered binting replace with decide which one to
use?

[Magno Machado]

Yes, look here for an exemple:

http://code.google.com/intl/pt-BR/webtoolkit/doc/latest/DevGuideCodingBasicsDeferred.html#replacement

--
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-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
Magno Machado Paulo
http://blog.magnomachado.com.br
http://code.google.com/p/emballo/

[Jens]

Sure you can. But the question is: Can you decide which implementation to use at compile time?

[Elhanan Maayan]

actually i allready took a look at the dev guide, that's where i got the idea from

i wish i had some example on how to use the RPC class in this way, i understand i still gonna need to create a servlet to extend a remote servlet only this time it would without any interfaces or async interfaces.

i don't see any reason why i should decide at runtime which protocol to use , mainly i don't want to couple a the application programmer to one specific api. which requests different implementations.

MY question is, is there framework for this?

can MVP4G help me in this?

On Tue, Jul 5, 2011 at 2:04 PM, Jens <jens.ne...@gmail.com> wrote:

Sure you can. But the question is: Can you decide which implementation to use at compile time?

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/5egQ3zmgknkJ.

[Thomas Broyer]

On Tuesday, July 5, 2011 1:46:50 PM UTC+2, Elhanan wrote:

actually i allready took a look at the dev guide, that's where i got the idea from

i wish i had some example on how to use the RPC class in this way, i understand i still gonna need to create a servlet to extend a remote servlet only this time it would without any interfaces or async interfaces.

i don't see any reason why i should decide at runtime which protocol to use , mainly i don't want to couple a the application programmer to one specific api. which requests different implementations.

You can very well use the GWT-RPC way and provide other implementations using <replace-with> or <generate-with> (with your own generator), or if you're using GIN, with a bind(MyServiceAsync.class).to(MyServiceAsyncImplJsonRpc.class).

I did that in my earlier project: everyone coded using the GWT-RPC pattern, but we didn't ever used GWT-RPC, all Async interfaces were coded by hand, doing "REST-like" calls to our server using RequestBuilder. The hard part, of course, is serialization, but here piriti or similar projects can help (we did it all by hand, and our "domain objects" were actually JavaScriptObject so we could simply use JsonUtils for the deserialization part; for serialization, we only had "simple" objects so we did it by hand, on a case-by-case basis).

You could do the same using RequestFactory interfaces, though it's probably a bit more complex (you can overcome this by just adding a few constraints though, such as "no more than one method invocation per RequestContext", FWIW that's how the current @JsonRpc "facet" of RF –introduced in 2.3– works, but it's client-side only: it allows you to easily consume existing JsonRpc services from your client code, not to build them on the server-side)

I mean: they're just interfaces, most of which *you* do write, so you're free to implement them the way you want (including using the "default" GWT generator).