Dundas charts are fantastic in terms of some of the charting ability. In configuration you can specify exactly how you want to store the charts you are creating. This includes memory and file system for the most part. However, there are some issues to be aware of when using some of the default handling capabilities with Dundas Charts. Check it out:
Memory – This is the fastest, easiest, best performance process to store your charts between creation and pickup. However, if your system is load balanced without some type of shared state device (i.e. State Server), you simply cannot use Memory as an option.
File System – Usually an alternative when storing in memory is not an option. Allows you to store to the created images to a location you specify on the file system. This location, unfortunately, has to be accessible via your website in order to load the images. This means for a load balanced system you may want to create a central share that both webservers can write too, that map to a virtual directory on each website of each machine. Also, the files will overwrite each other given the configured timeout period, but the files will never be cleaned up once created.
Obviously, if you can use memory for storing your charts, then you are golden from most perspectives. The problems and limitations arise when you begin using the File System functionality (likely for a load balanced environment). This is where you may need to implement a custom handler for your charts. Dundas provides an easy methodology for a custom handler (given you follow their pattern).
Firstly, you need to create your custom handler as follows:
Some things to know about this:
– Notice the class name is lower case. This is quite weird I know, but your class name has to be lower case for this to correctly implement the ImageHandler. In the dundas code itself, when it uses reflection to open the class, it uses a “ToLower”. Essentially, it won’t work if your class name is uppercase at all. TISK TISK DUNDAS !!!
– Implement Interface: Of course Dundas expected interface is defined by IImageHandler… so be sure to implement this.
– StorageSettings: This object is passed into each interface method (following). It contains all information from the configuration (including custom configurations you will want to use).
– Exists Method: Determines if the dundas chart exists – should return true or false indicator based on the key provided.
– Remove Method: Removes a specific Dundas image from storage with the specified key.
– Retrieve Method: Core method used when the handler requests an image. Return the image data into the output variable “data”.
– Store Method: Occurs when the chart is created (before it has been requested). Store the image in “data” given the key, for “Retrieve” usage later on.
Obviously in this custom handler class, you can easily store information however / wherever you want. Whether you want to store in a database or perhaps to a file system (which is not accessible via web), you have complete control at this point. You could potentially write to the file system and alter the name of the file based on an authentication key (i.e. the user or some other context related to your application). An example is a user specific application that associates an encrypted value to the file name based on the company name / user name / regular dundas key. This ensures uniqueness and security for storing and retrieving the charts.
The last thing you need to do is configure Dundas Charts to use your custom handler now. Alter / add the following app setting key/value:
<add key=”ChartHttpHandler” value=”handler=namespace.myimagehandler, projectname” />
Of course for configuration, you probably have some additional items you’ll want to store. So you can also add any additional items you want (can be complete custom), that you can pull out of the StorageSettings object in any of the interface methods:
<add key=”ChartHttpHandler” value=”ImageType=.png;MaxImages=5;handler=namespace.myimagehandler, projectname” />
You can also use other StorageSettings like the StorageType to determine if you should store in database, etc.
I have a query regarding Dundas Charts. We are using Dundas Charts in our project and we have found that the images generated by Dundas are named sequentially. Is there a way to fix it?
Here is the sample code:
If you notice the i= dcp_71c6fbda1E.png part. The dcp_71c6fbda1E.png is autogenerated by Dundas (I suppose), is there a way to fix it? I want to assign a Random Unique Id (GUID) to the Image instead of a sequential number / ID.
Any help in this regards is greatly appreciated.
Unfortunately your sample code did not come through in the message. From the sounds of it you are interested in naming the temporary image file dundas creates with your own naming scheme / mechanism. Using the custom dundas handler you get full control to name and store the files wherever you like.
However, the key you are referring too is what Dundas will provide back to you to request the image that was previously stored. This means, whatever you end up naming the file, you must be able to recreate the name of the based on this key that they provide to you in all of the methods (so a random guid would likely not work well).
That being said, there is a lot you can do depending on why you are looking to change the file name. In my own useage, I take the key dundas provides, concatenate that with the currently logged in username and application name, and throw this all into an MD5 hash, which would then become the name of the file (a more secure filename). This ensures security across load balancing, that no accidental users will get another users chart (which I had experienced under rare circumstances using the default dundas key).
If your interested in my hashing dundas handler, email me and I can send you some code: firstname.lastname@example.org
Or if you can provide more details on why you are looking to use a random guid, we can talk more about your specific scenario.