As mentioned previously, I'm creating a UI to allow 'normal users' to configure the Flex graph templates. My idea was to have the users enter the required info, then generate the config and dump it locally along with the SWF and a simple HTML page. This would allow them to easily preview the graph before it was released.
One small problem though: Flex/Flash sandboxing prevents access to local files, even when the SWF itself is local, which means that it can't read the config file. The net-usage flag allows you to compile the app with local file access, but only if you relinquish network access. Full access is possible, but only by modifying the Flash settings on each users's PC to set up trust. And of course, in our locked down desktop environment, users's don't have access to do that.
So I'm left with a couple of options. I could try and auto-deploy it to a webserver, but this is somewhat tricky as it needs to cater for concurrent users, and also requires the users to have access to the webserver.
Another option is to use the UI app to pull down all the network files locally, and run in local trusted mode. That may work - needs investigation.
Alternatively I could try and either get our desktop environment changed, but I don't like my chances.
I decided to go with deploying the config file to the webserver, because after some thought I realised that it was pretty easy. I'm using Notes for the client UI, which makes it fairly trivial to use the actual document the clients fills in as the config file. Modifying the Flex app to take the location of its config file as a parameter was also pretty easy - just using the FlashVars parameter when embedding the object.
So now, I'm hosting the Flex graph in the Notes DB, along with the config documents. Then whenever a user wants to preview the graph, a local HTML file is generated that embeds the SWF from the server and passes the location of that user's config file to the SWF. That, mostly, works quite well.
The problem now is that I've been somewhat protected by the dev environment. It seems that (and it's logical) the bin-debug directory is one of those special 'full trust' Flash locations, so any SWF in that dir can access local files and network resources. Now that I'm running on a server though, the SWF cannot access network resources that are in a different domain (see livedocs). So to get around this, I'll need to create a simple proxy script/agent/servlet to wrap the external server calls.
In a way it was good to find this now, as the call to the Excel2XML servlet would certainly have broken for the same reason once I had tried to deploy.
Hopefully tomorrow I'll get the proxy sorted, which will mean the bulk of the functionality for the client UI will be done, other than prettifying and cleaning up.