> That's a good guess, but you have to remember one thing: Javascript's > only number type is equivalent to Java's double. It's been a while > since I've looked at the RPC internals, so things may have changed, > but it has been true that a byte[] would be converted into the > equivalent of a double[], and then serialized.
Ouch, right, I faintly remember having read about these implicit conversions. > I'm curious about what you're doing with a byte[] on the client, Axel. I'm trying to write a file importer for GPS tracks where the user can use an upload form to submit the file. At the same time I'd really like to make use of a convenient RPC because the result will be a Route object. Now unfortunately, the form submit results are just a formatted HTML string returned by onSubmitComplete callback in the FormSubmitCompleteEvent. Since I'm not aware of any good way of assembling the Route object in a non-RPC servlet and serializing it through the servlet response so that I can easily deserialize it from the FormSubmitCompleteEvent, for the time I chose a rather inefficient but easy-to-write approach. I more or less "echo" the file and then have its contents in the client from where I can then submit them to an RPC doing the actual conversion, returning the Route object. It's expensive for the additional round-trip, but then again I wanted something working now that I may optimize later. I then encountered that the FormSubmitCompleteEvent contents are somehow altered by the browser. I therefore decided to Base64-encode and put it in between <pre></pre> to force the browser to leave the Base64 string alone. I then originally decided to decode on the client into a byte[] which would be the Java abstraction of arbitrary file contents (think of binary GPS track formats) and then submit the byte [] to the RPC doing the actual track decoding. After the trouble with the byte[] I now just keep the Base64 string and submit that to the RPC which then does the Base64-decoding on the server. All I need to do on the client now is string the <pre></pre> from the string. Although I like the clever trick with the double encoding you describe, I think I may stay with Base64 right now because it makes encoding/decoding more or less transparent to the client. Yes, it creates a hidden dependency between the echo servlet and the RPC implementation, but that's all on the server and I feel I can live with that for now. If someone can recommend a way to access the RPC serialization protocol as an API, I could perhaps use that in my echo servlet and do the conversion to a Route object in one round trip. I may still need to Base64-encode and wrap in <pre></pre> to avoid distortion of the form submit results by the browser, but I could then Base64-decode and afterwards RPC-deserialize on the client. That, I think, would be a good solution because it would save the extra round trip. The byte[] problem, at last, seems to he the price we have to pay with Java vs. JavaScript incompatibilities. Still, better performance in the RPC implementation for byte[] (de-)serialization I find desirable. Best, -- Axel --~--~---------~--~----~------------~-------~--~----~ 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-Web-Toolkit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/Google-Web-Toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
