Turbo GWT HTTP integration

[nmorel]

Turbo GWT HTTP integration

[nmorel]

Hello, thanks for your interest into my project :)

From what I understand, it seems you have no generator inside your framework. When you do a request, you explicit tell the class of the parameter and return types. The Requestor will then look for Serializer/Deserializer into some kind of Map I guess ?

What you can do is defining some new interfaces like GwtJacksonSerializer<T> extends Serializer<T> and GwtJacksonDeserializer<T> extends Deserializer<T>.
An user who wants to serialize a new type can create an interface MyTypeSerializer extends GwtJacksonSerializer<MyType> and call a new method on Requestor : registerSerializer(Class<T> type, Class<S extends GwtJacksonSerializer<T>> serializerClass). The requestor creates the serializer using GWT.create(serializerClass).
Once you have that, you just have to make a simple generator that will create an implementation containing :

• an inner interface InnerMyTypeSerializer extends ObjectWriter<MyType>,
• a call to GWT.create on this inner interface
• the implementation of the serialize method that just delegate the operation to the inner interface

If you have something else in mind, I can help :)

[reinert]

From what I understand, it seems you have no generator inside your framework. When you do a request, you explicit tell the class of the parameter and return types. The Requestor will then look for Serializer/Deserializer into some kind of Map I guess ?

Correct! The de/serializer is selected by matching both type (class) and content-type.

An user who wants to serialize a new type can create an interface MyTypeSerializer extends GwtJacksonSerializer<MyType>

I really would like to skip this step! You were clear about how to implement the generator, and I think this is the way to go. But don't you know if it's possible to, instead of declaring a new interface, just putting some annotation on top of model class, achieve the binding to the generator?

I mean, is it possible to bind some generator by resorting to annotations instead of types (interfaces)? (This is a GWT question =P)

I imagine one would put an annotation just telling the content-type patterns to handle on serializing and deserializing.

@GwtJacksonSerialize({"*/json", "*/javascript"})
@GwtJacksonDeserialize({"*/json", "*/javascript"})
public class Book { ... }

Indeed, @GwtJacksonSerialize and @GwtJacksonDeserialize would have application/json as default content-type pattern.

I find this way more interesting. What do you think? Is it possible?

[reinert]

I mean, is it possible to bind some generator by resorting to annotations instead of types (interfaces)?

Yes, it's possible: http://stackoverflow.com/questions/10521016/is-it-possible-to-find-all-classes-annotated-with-myannotation-using-a-gwt-gene :)

But, how would I integrate with the Requestor? Maybe I would need to create something inside the Requestor with Defferred Binding.

[nmorel]

I was going to say it's possible :)
You could have an internal interface like DefaultSerdesFactory with just a getter for serializer and deserializer maps. Your requestor calls GWT.create on it and initalisze its map with those. If the user gives other serializer, it overrides the default ones.

The generator of DefaultSerdesFactory has just to iterate through all types looking for annotations and initalize the map.

I don't know if there are any drawbacks using this method. I'm not sure how it will work with the incremental compilation coming soon if your generator has to loop through all type everytime. Could be a good question to ask on GWT forum!

[reinert]

Nice! Thanks for the insights!

[nmorel]

Forgot something, the generator also have to generate inner interfaces extending gwt-jackson interface for every type. You could skip the GwtJacksonSerializer by creating anonymous class that directly delegate to gwt-jackson.

If I'm not clear, I can give an example :p

[reinert]

Sure. Otherwise I couldn't use gwt-jackson's generators.

[reinert]

Good news. It worked like a charm! :)

I'm still improving the code, and will publish the solution ASAP,

I would like your opinion about the annotation name. I'm using GwtJacksonSerialize and GwtJacksonDeserialize. Is it good enough? Do you suggest any other?

ps: I'm not sure what is the best approach to test generators. How do you do it?

[nmorel]

I'm glad it worked :)

It's a bit long maybe and too close to the implementation. If you want to change the library or add an other, maybe you should pick a more generic name like JsonSerialize and JsonDeserialize. These way, it will be transparent to the user if you change anything in the implementation.

To test them, I just use the GwtTestCase and test the generated implementation.

[nmorel]

I also looked at your project. To add your callback, maybe you should decompose in two methods onSuccess() and onFailure(). This way, your callbacks only have one method and are good candidates for FunctionalInterface and lambda.

[reinert]

Hum .. thanks for the insights!

I've found the name too long too. I'll accept your suggestion about the annotation names.

As to the callbacks, yeah, I'm planning to change the callbacks to one method callbacks only. Initially, I thought it would be good to rely on GWT default types, but now I don't see this as so important, specially because I'm reusing simple types as callbacks.

Actually, I plan to implement a general purpose Deferred API (in -Core) and use it on Turbo GWT HTTP. I miss one for GWT.

[reinert]

Additionally, I will create another repo for this specific integration. About the repo's name, would you think "turbogwt-jackson" could cause some confusion? If so, I was thinking about "turbogwt-gj".

[nmorel]

It could if people think you are also developping a jackson serialization mechanism.
Maybe add a -impl or "turbogwt-http-gwt-jackson" :D I don't know :)
As long as you specify in the readme it's the integration of gwt-jackson inside your library, you can pick the name you like I think!

[reinert]

I guess I'll let "turbogwt-gwt-jackson"