How do I throw all kinds of objects back and forth between client and server?

[Navigateur]

I want to be able to have the same object do client-specific behaviour
when on the client-side (UI etc.), and do some server-specific
behaviour when on the server-side (database etc.). So I want the same
object to hold both a Widget (unused/null on the server side) and a
server-specific Java object (unused/null when on the client side).

To achieve this, do I have to create some dummy GWT "emulation" for
the unused/null server-specific object on the client side and can I do
the same for the unused/null "Widget" on the server side? Or does it
work straight out of the box when you put it in the "shared" package?
If not, what's the best way of making this work?

My reason is simplicity. I don't want to have to put their respective
client and server behaviours away from the object.

[Thomas Broyer]

On Friday, September 2, 2011 12:18:36 PM UTC+2, Navigateur wrote:

I want to be able to have the same object do client-specific behaviour
when on the client-side (UI etc.), and do some server-specific
behaviour when on the server-side (database etc.). So I want the same
object to hold both a Widget (unused/null on the server side) and a
server-specific Java object (unused/null when on the client side).

To achieve this, do I have to create some dummy GWT "emulation" for
the unused/null server-specific object on the client side

Yes.

(read about "super-source" here: http://code.google.com/webtoolkit/doc/latest/DevGuideOrganizingProjects.html#DevGuideModuleXml )

 

 

and can I do
the same for the unused/null "Widget" on the server side? Or does it
work straight out of the box when you put it in the "shared" package?

"shared" is nothing special, just a convention. There's no such things as "shared code" in GWT; everything that GWT sees (in the <source/> paths of your modules) has to be translatable to JS (i.e. "client code"); the client vs. shared vs. server is just a convention, where "server" code shouldn't use "client" code, to make it clear which code an run in both a browser (compiled to JS) and standard VM (server, or possibly Java client, such as Android, an applet or a desktop app).

But having a field of type Widget won't harm as long as you don't initialize the class (i.e. use it); so there's nothing special to do on the serer side.

 

My reason is simplicity. I don't want to have to put their respective
client and server behaviours away from the object.

But then you don't have a clear separation of concerns, as a single class plays all "shared", "client" and "server" roles, where "client" and "serer" are mutually exclusive.

You'd probably better abstract things behind an interface, and implement it in both your server-side specific object and your widget. It would have the benefit of adding testability of your code using a mock of that interface.

[J.Ganesan]

On Sep 2, 3:18 pm, Navigateur <naveen.c...@gmail.com> wrote:
> I want to be able to have the same object do client-specific behaviour
> when on the client-side (UI etc.), and do some server-specific
> behaviour when on the server-side (database etc.). So I want the same
> object to hold both a Widget (unused/null on the server side) and a
> server-specific Java object (unused/null when on the client side).
>
> To achieve this, do I have to create some dummy GWT "emulation" for
> the unused/null server-specific object on the client side and can I do
> the same for the unused/null "Widget" on the server side? Or does it
> work straight out of the box when you put it in the "shared" package?
> If not, what's the best way of making this work?
>
> My reason is simplicity.

Pack as much as possible in the shared code, that is, to the extent
the emulated JRE admits of. Have helper classes in your server side
for database etc and in your client side for UI. This is close to
developing a client-server application in java swing. The emulated JRE
has nice java.util.Collection which is handy for domain modelling, UI
handling and persistence. I think this is not only a simple way of
developing but also maximally takes advantage of GWT.

J.Ganesan
www.DataStoreGwt.com