3

I've been working on a Web Server which produces XML data to be used for FusionCharts. After days of unsuccessfully trying to come up with a standardized object structure in Delphi to wrap the XML production for these charts, I've decided to look and see if someone has already done so.

What I'm trying to do is build an object structure in Delphi which wraps the functionality needed to produce XML data for the FusionCharts. There are 42 possible types of charts, each of which requires a slightly different XML structure. The object structure I started building simply wraps the ability to specify the common properties of one of such charts and generate XML data on the fly based on these properties. It of course also consists of handling multiple data-sets, each of which is used for a different series in the chart. There are also some oddball charts with a combination of possible datasets, which is where I got lost in trying to implement this structure.

I quickly came to realize that this is a huge task, and would like to see if someone has already done such a thing. I know there is a VCL library out there to display FusionCharts in an application, but this is not what I need. I just need to simply produce the XML data to be passed back through the Web Server to the HTTP client.

Has this already been done? If not, then any tips or pointers as to how to accomplish this? I was getting ready to make one single object called TFusionChart and wrap everything inside of it (with a ChartType property), but there are 42 possible charts, and this would be a huge mess. I may also create 42 different objects, one for each chart, but this would have redundant code.

PS - I'm willing to start a Bounty for this question, it is rather important.

UPDATE

Just to explain the existing structure of mine a little bit, I have one base component called TFusionChart. This class holds everything that all charts have in common, including category names, title, background, etc. None of the actual charts are based off of this. From this class, I then have TFusionChart2D and TFusionChart3D. Then I have 4 more called TFusionChartSingle2D, TFusionChartMulti2D, TFusionChartSingle3D, and TFusionChartMulti3D. From these 4 classes, I then begin creating the actual chart components. I plan to have a component for each of the possible charts that are available.

The problem I'm facing is confusion as to how to manage the data to be contained. Some charts can have a combination of one for example: multiple series in columns, a line series, and stacked data within the columns. This one chart alone would have a very unique way of storing its data, which is difficult to share with other types of charts, for example, a simple single series column chart.

I tried the XML Data Binding capabilities as described in answer below, but this was far too massive of a solution that I abandoned it. Again, because of the fact that there are 42 types of charts. Each chart would mean a few thousand lines of code.

Jerry Dodge
  • 26,858
  • 31
  • 155
  • 327

2 Answers2

1

I suggest you to use XML Binding to build the classes hierarchy for XML generation.

For the purpose, you can refer to the following XSD resources related to Fusioncharts:

Please, don't forget to share if you find other uptodate XSD resources.

Edit:

Using XML Binding appears too be an overkill as the OP points out, I suggest an alternative use of them :

  1. Strip off every unneeded features to get bare XSD still compatible to with Fusioncharts specifications and compliant too to the OP requirements.
  2. Process the bare XSD with appropriate tool to get the corresponding XMI files (e.g. Entreprise Architect)
  3. Feed a Case Tool with the XMI files and get down to the real job: Design of the light classes for Fusioncharts XML generation.
menjaraz
  • 7,551
  • 4
  • 41
  • 81
  • The XML Binding seems to be a very powerful tool, except, while following a few different tutorials on this and doing exactly what's described, I come across some errors "Interface Not Supported" (which is a matter of another question). But thanks! – Jerry Dodge Mar 22 '12 at 16:59
  • This has become so huge of a project, that I've decided not to utilize the XML Binding and continue building my structure from scratch. This is simply because 42 units with thousands of lines of code each is a little overkill. I don't even need each and every possible feature, and I'd like to make a component out of it too. – Jerry Dodge Mar 23 '12 at 01:57
  • Are at least the XSD of 06 December 2010 uptodate ? Still you will likely have to do with with thousands of lines of code to make a component adressing the 42 possible type of charts with the complexity it involves. If you feel comfortable with XML/XSD, you can make an attempt to write downsized XSD version (slim but still compliant) to get rid of every bloated features. – menjaraz Mar 23 '12 at 05:17
  • Well, strictly speaking, the "thousands of lines per graph" using the XML Binding still extends to even more lines of code with the entire XML back-end which you don't even see (the DOM). The customization I'm doing won't require these other massive back-end structures, meaning less code involved in the actual process. – Jerry Dodge Mar 24 '12 at 01:28
  • Thanks for the edit, although I've re-thought everything and decided to only build object structures to wrap the charts that my system needs, and not all the various charts that are available. For example, `TSalesSummaryChart`, `TInventorySalesChart`, `TSalesPersonChart`, etc. – Jerry Dodge Mar 27 '12 at 23:35
1

I would try to create one class per chart type, but use base classes to keep similar charts together. The class should only be the "data holder" for the chart data and chart setup, and delegate the XML output creation to a separate class. This makes it easy to try and switch between different solutions for the output generation, or to plug in other output formats.

mjn
  • 36,362
  • 28
  • 176
  • 378
  • This is in fact how I started it, first `TFusionChart`, then `TFusionChart3D` and `TFusionChart2D`, then `TFusionChartSingle2D`, `TFusionChartMulti2D`, etc. Then I base all the actual charts on those ones. The first 3 aren't used as bases of any chart. – Jerry Dodge Mar 23 '12 at 01:59