On Oct 23, 3:54 pm, Jason Essington [EMAIL PROTECTED] wrote:
You could either return a URL from your RPC and then create an
imageWidget using that URL, or you could simply skip the RPC
altogether and create a GET request URL that presumably ends at a
servlet capable of returning your
2008/10/23 Jim Freeze [EMAIL PROTECTED]
Hi
On Thu, Oct 23, 2008 at 9:54 AM, Jason Essington
[EMAIL PROTECTED] wrote:
Although you could certainly return the bytes of an image via RPC,
once you have them on the client side, there is no way to actually
turn those bytes into an image
Hi
On Thu, Oct 23, 2008 at 9:54 AM, Jason Essington
[EMAIL PROTECTED] wrote:
Although you could certainly return the bytes of an image via RPC,
once you have them on the client side, there is no way to actually
turn those bytes into an image (or even save those bytes to the file
system).
That's one solution, with the following caveats:
1) it's fine if you don't plan to support IE
2) base64 adds 33% to the actual bytecount
3) URIs are limited in size (different platforms tend to have
different limits)
4) Data URIs don't benefit from browser caching.
-jason
On Oct 23, 2008, at
Well, the RPC could return the URL of an image. You could create the
image on the file system with some random name, and return that URL to
the browser. If a random name isn't secure enough, you could use a
servlet filter or other non-GWT technology to only allow that use to
access that
