"domain object" vs "message payload"; Yes, this is the point. We came from
RequestFactory which works quite good with "domain object" models, we use
one model for each type, this model is the same in the server and the
client, and all views use the same model.
So, responding to the 'JSON object recreation in the client'; JsInterop
makes trivial Object recreation, you map your messages in a very explicit
and clean manner having almost zero overhead, but you should take care of
this "domain object" vs "message payload" model strategy. JsInterop doesn't
work well with "domain object" models (so questions like how can you return
a Set or a Map are currently hard to answer, and makes no much sense in the
"message payload" side), but it will work much better with "message
payloads". We are getting really good result using plain classes without
methods. But it's important to think on terms of "message payloads", you
should try to avoid fancy things, using only primitives (plus Boolean,
Double and String), arrays or other @JsType models. We end up with lot of
services like this. This models frequently do not need any special
annotation, but are so simple that most JSON encoder works correctly
(Jackson, gson, moshi...) and obviously JsInterop.
@AutoRestGwt
@Path(RESOURCE_TOOLS)
@Produces(MediaType.APPLICATION_JSON) @Consumes(MediaType.APPLICATION_JSON)
public interface ToolsRestService {
@GET @Path("build")
Single<BuildInfo> getBuildInfo();
@JsType(namespace = GLOBAL, name = "Object", isNative = true)
class BuildInfo {
public int buildDate;
public String version;
public String commitId;
public String javaVersion;
}
@GET @Path("system")
Single<SystemInfo> getSystemInfo();
@JsType(namespace = GLOBAL, name = "Object", isNative = true)
class SystemInfo {
public double startupTime;
public double totalMemory;
public double freeMemory;
public double usedMemory;
}
}
I like to think of this classes as something like JSON (JavaScript Object
Notation) but in Java and to define the scheme instead of the object itself
so JOSN (Java Object Scheme Notation), i.e. a subset of Java just to define
objects schemes.
On Saturday, August 20, 2016 at 12:54:24 AM UTC+2, Thomas Broyer wrote:
>
> I think the crux is thinking in terms of messages (payloads) rather than
> "domain objects". This applies to DTOs vs domain objects too, with RPC or
> RequestFactory or whatever.
--
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 [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/google-web-toolkit.
For more options, visit https://groups.google.com/d/optout.
