The Graph component in DesignBais is great. The documentation might make the BASIC code for graphs look complex, but after you do it just once, you’ll realize it’s quite simple. This article discusses how to generate graphs using alternative components. As a bonus we’ll see how DesignBais can be integrated with lots of third-party products and services, to provide functionality for your users far beyond what’s “in the box”.
First, let’s break down exactly what the graph component in DesignBais is. It’s a third-party server-side component with an Application Program Interface (API). Like DesignBais, it has its own variables that can be set, and various subroutines (functions or “methods”) which can be called, it then draws an image that is sent to the browser. How well any component does that task is up to the component developers. DesignBais International elected to use the Microsoft Office Web Control, so we can make use of whatever is in there. The API for the OWC corresponds to the DB Reference manual: You set a title and its properties, X and Y axis data, you plug in your numbers, then tell it to render.
Why should we use OWC through the DesignBais interface? One reason is because DBI made it easy for us to do so, so why not? Above all else, DesignBais facilitates the creation of fairly complex and highly interactive web applications without the author having to know anything about the internal plumbing. This is just another example of that. If you are happy with the graphing capabilities in DesignBais, look no further for alternatives, what’s in there will satisfy about 95% of the developer and user audience.
Also, at the moment it’s the only graphing component that DesignBais natively supports, but the OWC isn’t the only component that can be used like this. As we see below, there are many similar components in the market, some for fee, some for free, some open source. The trade off is that for alternative functionality we will need to do our own coding of the “plumbing” that gets MV data into some other component and then out to the browser. After we discuss how to use other components in this way, we’ll come back to discuss the relative merits of using the OWC – with or without the DesignBais-specific interface.
Assuming we have needs beyond the provided OWC functionality, the objectives are:
- Find another component.
- Identify the API.
- Get settings and data from BASIC to the component through the API.
- Get the resulting graph into a DesignBais web page.
For DesignBais v1.1, long before the Graph component was even added, I wrote my own primitive graph generator. Rather than using a third-party component I did it the hard way by drawing boxes and lines, adding color at specific coordinates, manually positioning text, etc. Sometimes I can be such a numbnut. I highly recommend you take advantage of someone else’s focused effort in this area, even if it costs a little.
- ZedGraph – free, open source, highly capable
- NPlot – free, open source, used in commercial code but not well maintained anymore
- jGraph – free visualization tools for Java developers
- .netCharting – see their guages, dials, and maps too
- Data Dynamics – see their SharpGraph product as well as DynamiCube and others
- DeveloperExpress – see xtraChart
- Syncfusion – EssentialChart
- Dundas – charts, guages, diagrams, etc
- Modulus FE – StockChartX is “a component designed BY traders, FOR traders”
Don’t get sticker shocked by high costs for some components. Just look at what they do, decide if you need that functionality, and compare the cost and features with other offerings. Also be sure to check whether the cost is per-server, per developer, etc. Don’t assume that free and/or Open Source means less functionality than commercial-ware, or that the components are inherently better or worse than commercial offerings.
It may not matter if you get a component that was created for thick vs thin client development – if all you’re doing is generating an image it doesn’t matter how you create it or where that image goes. We’ll get to this soon.