Design pattern for setting common chart options?

[indio]

I want to make different TimeSeries charts. These charts are all timeseries, but they differ in what they are plotting, eg one might be about speed/s and another about petrol consumption.

They share though many properties like backgroundPaint, timeAxis formatting, colors, legend styles and so on.

What is the best way to create a basic graph out of some data, that will "inherit" these common features without me having to set them each time a new time series graph is required for a different dataset?

I can for example pass all graphs through a static void setCommonProps(JFreeChart chart) which will set these things. But this seems not as such a good solution. Could any patterns help?

[indio]

I would really appreciate an answer to this question..

Why is this forum organised like this? No sections just a huge bag of questions that don't get answered.

This should be a common problem to jfree developers.

[paradoxoff]

I want to make different TimeSeries charts. These charts are all timeseries, but they differ in what they are plotting, eg one might be about speed/s and another about petrol consumption.

They share though many properties like backgroundPaint, timeAxis formatting, colors, legend styles and so on.

What is the best way to create a basic graph out of some data, that will "inherit" these common features without me having to set them each time a new time series graph is required for a different dataset?

I can for example pass all graphs through a static void setCommonProps(JFreeChart chart) which will set these things. But this seems not as such a good solution. Could any patterns help?

Why is your solution not such a good one? I would do something similar. I would probably not provide a complete JFreeChart instance as parameter, but just the parts of which a JFreeChart is composed, similar to the static createXXXCharts methods of the ChartFactory.
Note that the method doesn't have to be static. It shouldn´t matter whether the method belongs to a class or an instance.
Regards, paradoxoff

[david.gilbert]

Why is this forum organised like this? No sections just a huge bag of questions that don't get answered.

Thanks for your feedback. The answer is: there are lots of questions, and just a few volunteers answering them.

[david.gilbert]

I can for example pass all graphs through a static void setCommonProps(JFreeChart chart) which will set these things. But this seems not as such a good solution.

That seems like a reasonable solution to me. At some point, we'd like to implement some kind of chart "theming" mechanism that could take care of this. But it hasn't reached the top of the priority heap yet (sometimes because I spend too much time answering questions here in the forum).

[indio]

Thanks for the reply guys. I don't mean to be disrespectful, I 'm just the average guy that complains when nobody talks to him . In any case, the point I was trying to make is with better classification more questions could be answer by the public and not the devs.

I don't really like my solution because you have to do more work every time. Why call more functions explicity when some OO goodness can make that go away.

I was thinking about a solution today, but haven't checked the class definitions yet to see how exactly it can be achieved. How about extending the factory method with one that gets exactly the same arguments, but also sets the common props for you? The factory method is static from what I gather, so you could simply not extend and just make a separate class that calls it, sets some things and returns like the createXXXchart() does.

Every time you want a "themed" chart, as david gilbert puts it, you can call the custom factory method. What d'ya say?

[matinh]

Cewolf introduces the ChartPostProcessor interface which provides the method processChart(chart, params) . What about a similar interface (params is probably not need here) that may (optionally) be passed to the ChartFactory methods. After the chart is created by some createWhateverChart() method the ChartPostProcessor could be called to perform some formating.

Just some ides...

hth,
- martin

[sturodgers]

indio,

I agree with the intent of the approach you outlined above.
The pattern you might use is a Facade. Basically write several classes that instantiate the settings you want. These classes use the ChartFactory as needed. And do all the customized settings.

You can further streamline the approach by writing a class with one or two simple enum parameters that define your themes for the charts. This class calls the middle layer of classes as needed based on the simpler parameters.

In the end you have one class with a defined set of "styles" which does all the work for you.

Best regards,
Stu

[david.gilbert]

I don't mean to be disrespectful, I 'm just the average guy that complains when nobody talks to him .

Sure. The same "average guy" posts in the forum or e-mails me most weeks. It's one of the lesser joys of running a free software project.

[indio]

sturodgers: That is the kind of reply I was looking for. Thanks!

david.gilbert: I know that its tough to do this. I have an open source project under my belt, of course nowhere near as successful and useful as yours. Thank you.