Manually serializing objects on the client

[Ryan Stewart]

In tracing through the client-side serialization process, it doesn't
seem to be nearly as friendly as server-side serialization is made by
the RPC class. Is there some easy way that I haven't seen to serialize
objects on the client for sending back to the server, or is there
maybe a reference somewhere that specifies the process or format for
client-side serialization?

[Todd]

What do you mean? If you're using GWT-RPC, it hides all serialization
from you. You just pass your objects (on either the client or server
side) and it does everything for you. I'm not sure what you mean by
"not nearly as friendly as server-side". Perhaps you should
considering using JSON versions of your objects?

[Ryan Stewart]

On May 29, 7:31 am, Todd <ziftyt...@gmail.com> wrote:
> What do you mean? If you're using GWT-RPC, it hides all serialization
> from you. You just pass your objects (on either the client or server
> side) and it does everything for you. I'm not sure what you mean by
> "not nearly as friendly as server-side". Perhaps you should
> considering using JSON versions of your objects?
>

I mean that the com.google.gwt.user.server.rpc.RPC class exposes a
nice interface for working with GWT serialization on the server:
<http://google-web-toolkit.googlecode.com/svn/javadoc/1.4/com/google/
gwt/user/server/rpc/RPC.html>

I was hoping there was a similar mechanism on the client side, though
I don't believe there is.

[Todd]

I believe the GWT compiler is what's creating the code to do the
client-side serialization. If you're using GWT do make your RPC calls,
you don't need to worry about serialization on the client side, as it
does everything for you. The RPC class on the server side is really
meant for tying in other frameworks such that they can process GWT-RPC
calls from a client.

If what you're trying to do is reconstruct an object on your own from
the client-side, JSON is probably your best bet, as GWT's method of
serializing isn't documented (from what I can find at least).

[Ryan Stewart]

On May 29, 3:14 pm, Todd <ziftyt...@gmail.com> wrote:
> I believe the GWT compiler is what's creating the code to do the
> client-side serialization.

I believe you're right.

> If you're using GWT do make your RPC calls,
> you don't need to worry about serialization on the client side, as it
> does everything for you.

I'm having to go outside of GWT for something I'm trying to do as
referenced here:
http://groups.google.com/group/Google-Web-Toolkit/browse_frm/thread/d6e564211b89cce1/e62044ed48770613

> The RPC class on the server side is really
> meant for tying in other frameworks such that they can process GWT-RPC
> calls from a client.

Yes, that's already in place.

> If what you're trying to do is reconstruct an object on your own from
> the client-side, JSON is probably your best bet, as GWT's method of
> serializing isn't documented (from what I can find at least).

Yes, it seems quite hidden from public view. It uses a
"ClientSerializationStreamReader" and
"ClientSerializationStreamWriter" to handle the I/O, and the RPC calls
are encoded as strings consisting of a string table and a series of
integers denoting keys into the table. Each entry is separated by a
single character with the value 65535.

I understand most of it and could reproduce it easily, but who knows
if or when the format will change? That's why I wanted to see if there
was some kind of well-known, central point of management.

[Isaac Truett]

I've never done it myself, but I believe manually serializing an
object on the client goes something like this:

SerializationStreamFactory factory =
(SerializationStreamFactory)GWT.create(MyService.class);
SerializationStreamWriter writer = factory.createStreamWriter();
writer.writeObject(myObj);
String serializedObject = writer.toString();

Note that GWT RPC client- and server-generated serial formats are NOT
the same. That means you can't deserialize the string created above
using a stream reader created from the same factory object because it
expects the serial format generated by the server.

Hope this helps.

[Dave LeBlanc]

You might also want to look at the Hibernate4GWT project - I believe they do exactly what you're describing (lazy loading of collections via server calls), and I would assume it's done in a synchronous fashion, as there's no special magic that the client has to do to load a lazy object.

Given that, I've never actually used this tool in a lazy loading mode, but this is what I believe it does.

Your discussion is timely because our project is facing some big deserialization costs in the fat objects we're passing around.  Something to handle this for us transparently would be really nice.

Now if you could use continuations on the client side, that could give you a non-blocking async call, and have the developer use it in a straightforward synchronous manner.  (http://trimpath.com/blog/?p=28  seems to talk about javascript continuations).

Good luck!

 -Dave...

--
Dave LeBlanc <david....@gmail.com>

[jdwyah]

Hey Ryan,
I was playing around with this for http://code.google.com/p/tocollege-net/
(the idea was to serialize an object on the client and put it in a
gears database) but as Isaac mentions, the client deserializer won't
work on the resulting string. I'd love to hear if you find a good way
around this. I ended up storing JSON in the gears DB.
http://code.google.com/p/tocollege-net/source/browse/ProGWT/trunk/src/main/java/com/apress/progwt/client/gears/SimpleGearsDatabase.java
-Jeff

> > On Thu, May 29, 2008 at 12:25 AM, Ryan Stewart <zzant...@gmail.com> wrote:
>
> > > In tracing through the client-side serialization process, it doesn't
> > > seem to be nearly as friendly as server-side serialization is made by
> > > the RPC class. Is there some easy way that I haven't seen to serialize
> > > objects on the client for sending back to the server, or is there
> > > maybe a reference somewhere that specifies the process or format for
> > > client-side serialization?
>
> --

> Dave LeBlanc <david.lebl...@gmail.com>

[Ryan Stewart]

On May 31, 4:55 pm, "Isaac Truett" <itru...@gmail.com> wrote:
> I've never done it myself, but I believe manually serializing an
> object on the client goes something like this:
>
> SerializationStreamFactory factory =
> (SerializationStreamFactory)GWT.create(MyService.class);
> SerializationStreamWriter writer = factory.createStreamWriter();
> writer.writeObject(myObj);
> String serializedObject = writer.toString();
>
> Note that GWT RPC client- and server-generated serial formats are NOT
> the same. That means you can't deserialize the string created above
> using a stream reader created from the same factory object because it
> expects the serial format generated by the server.
>
> Hope this helps.
>

Thanks, Isaac! This is just the sort of thing I was looking for. I'll
definitely look into this further.

[Ryan Stewart]

On Jun 1, 9:34 am, "Dave LeBlanc" <david.lebl...@gmail.com> wrote:
> You might also want to look at the Hibernate4GWT project - I believe they do
> exactly what you're describing (lazy loading of collections via server
> calls), and I would assume it's done in a synchronous fashion, as there's no
> special magic that the client has to do to load a lazy object.
> Given that, I've never actually used this tool in a lazy loading mode, but
> this is what I believe it does.

I've spent 30 minutes or so looking over the Hibernate4GWT project,
and I don't believe it actually handles lazy loading from the client.
Eventually I'll look into it more, and if our goals line up, I might
just contribute to that project. For now, I'm going to continue down
my own path.

> Your discussion is timely because our project is facing some big
> deserialization costs in the fat objects we're passing around. Something to
> handle this for us transparently would be really nice.

I agree!

> Now if you could use continuations on the client side, that could give you a
> non-blocking async call, and have the developer use it in a straightforward
> synchronous manner. (http://trimpath.com/blog/?p=28 seems to talk about
> javascript continuations).

I'm not sure I follow you on this, but I'll read up on it. Are you
saying the developer using the code would add a continuation or that
the continuation would be within my code? If within my code, it
becomes a problem of how to have javascript wait. I've got another
thread concerning that issue here:
http://groups.google.com/group/Google-Web-Toolkit/browse_frm/thread/d6e564211b89cce1

[Ryan Stewart]

On Jun 2, 6:46 am, jdwyah <jdw...@gmail.com> wrote:
> Hey Ryan,

> I was playing around with this forhttp://code.google.com/p/tocollege-net/

> (the idea was to serialize an object on the client and put it in a
> gears database) but as Isaac mentions, the client deserializer won't
> work on the resulting string. I'd love to hear if you find a good way

> around this. I ended up storing JSON in the gears DB.http://code.google.com/p/tocollege-net/source/browse/ProGWT/trunk/src...
> -Jeff

This restriction shouldn't be such a problem for me as I'm planning to
always make a round trip to the server right now; however, if I end up
sending some suggested patches back to GWT, they might include some
changes to this mechanism to make it a bit more friendly.

[stuckagain]

Hello,

@Isaac
The SerializationStreamFactory is something I can not find... is there
some other class I need to use maybe ?

I need to do this because I need to call a RPC right after the upload
of a file, I want to avoid doing a roundtrip, so I want to have the
possibility to do a RPC call, that could contain uploaded files as a
parameter. This way I do not need to worry of session affinity in a
cluster since everything can be given in one call.

BTW: That would be a great feature request for GWT: Support some kind
of upload mechanism like it was just a regular parameter. The
FileUpload widget is a bit a cludge that does not fit with the rest of
the RPC. Why not support the possibility to call a RPC method with an
InputStream or similar parameter like this:

public boolean uploadAndProcessImage( InputStream pFile, String pName,
String pOwner );

InputStream could be replaced with some GWT specific type ofcourse.

David

> > client-side serialization?- Hide quoted text -
>
> - Show quoted text -

[Isaac Truett]

GWT can't because JS can't. JS doesn't have access to the file system
for security reasons. You have to use a form and post the file. If you
want to send data in addition to the file, either piggy back on the
form submission or send a separate async request.

[Ryan Stewart]

On Jun 4, 9:01 am, stuckagain <david.no...@gmail.com> wrote:
> Hello,
>
> @Isaac
> The SerializationStreamFactory is something I can not find... is there
> some other class I need to use maybe ?

[...]

Refer to Isaac's post to see why you can't do what you're trying to,
but as to this question, the SerializationStreamFactory was introduced
in GWT 1.5.

[stuckagain]

Hi,

I'm not talking about giving access to the file stored on the client
PC. I know the limitations of a browser.

What I am talking about is the fact that we have to upload files using
for example apache-fileupload and then use RPC to do something with
it.
In a cluster that means 2 roundtrips and if you don't have session
affinity the second request will be directed to potentially a
different node. As a result the stored file will not be available
unless we store it in a database or a location accessible by the rest
of the cluster nodes.

I want to combine the FileUpload and the rest of the RPC call that
actually needs to be invoked with this uploaded file in one Multipart
upload and let the servlet takes care of storing the file on the
server and giving the reference to the called RPC method in one
operation. The part that I have missing is binding parameters to the
uploaded files, right now thread locals are used. But it would be much
nicer if some RPC request parameters would be automatically filled in
with an object that gives access to the uploaded files.

This can be done since we have implemented something that does it. We
are using the serialization of GWT (through a generator since we found
no other solution in 1.4 - hence my previous question- put it in a
hidden field of the File upload request and deserialize the request on
the server side. We need to potentially upload more than one file at a
time.

File uploads in GWT do not really fit in with the rest of the RPC
system and it would be great if GWT were able to hide these details
from the developer. FileUploads are a bit a hassle right now since we
are left to our own devices to handle the upload (back to parsing post
parameters/fields). Client side you must put it in a Form, make sure
that it is set to Multipart and server side you need to use appache-
fileupload, parse the parameters and from there how do you go to the
rest of the server side when everything we have is RPC servlets ? We
can not forward since we need to have access to the serialization/
deserialization.

David


On Jun 4, 4:51 pm, Ryan Stewart <zzant...@gmail.com> wrote:
> On Jun 4, 9:01 am,stuckagain<david.no...@gmail.com> wrote:> Hello,