Committed new feature to trunk at revision 37408 and to the p01 tag at revision 37410.

The Javascript API has a new function 'exportToServer()', which gets the Base64-encoded PNG image and sends the data in a request to the server.

The component has a new attribute 'imageExportListener' that specifies a method listener that takes a 'ChartImageExportEvent' argument and is triggered when an 'exportToServer()' call is made in the client. The method ChartImageExportEvent.getBytes() returns a byte array representing the PNG image.

The class org.icefaces.impl.util.Base64 was augmented to include Base64 decoding utilities, extracted from Apache Commons Codec 1.8.

The file sizes are small enough that the simple approach of passing the byte array and image content type to the application via the event would be the simplest and most flexible. The file system accessing option would expand greatly in scope to handle all possible scenarios, so I advise against it.

I've managed to export the image to the server. It works in the following way: I added the exportToServer() function to the javascript API. When called, this function calls the jqplotToImageStr() function from the underlying API to obtain the Base64-encoded image. Then an ajax request is made to the server, adding this string as a parameter. In the server, when decoding the request, we check if it's an export request and in such case we decode the Base64-encoded image string to a byte array. In my test case, I write the byte array to a hard-coded file in my file system. I verified that the resulting file represents the same image on the browser.

What's left to do is to decide how we're going to allow the developers handle the resulting image file, especially in regard to naming it and specifying the location to save it. Three options come to mind:

• Adding support for a listener method that will be invoked on an export-to-server action and passing the byte array in the event object, letting the application developer decide what to do with the byte array (e.g. writing it to the file system, saving it in a database, etc.).
• Adding component attributes to specify the location and name of the file, similar to ace:fileEntry.
• Adding context parameters to specify the location to save the files, and naming the files in a predictable way like containing the date and time, etc.

Apparently the image export library that we use generates a PNG image in base64 encoding right in an img tag, so we should be able to put that base64 text into a hidden input field, for uploading to the server, and have it write it out as a file.

That's probably best implemented as adding a client event for image export, where the custom event would be given the un-encoded image byte[] plus png content-type. We should evaluate how that client event should integrate with the existing client-side image export as well. Then the application would receive the event and deal with the file saving itself.

Assigned to Mark for re-assignment. As a new feature request, this may not be suitable for inclusion in the upcoming EE patch so I've tracked targeted it for 3.4 for the time being. I have to think that there may be a workaround that could be found since the image bytes are generated on the server.