4 Jul
2012
4 Jul
'12
8:22 a.m.
On Jul 3, 2012, at 7:18 PM, Vincent Massol wrote:
Hi Andreas,
On Jul 3, 2012, at 11:10 AM, Andreas Jonsson wrote:
Note that one thing we had in the past that was nice was a Chart Wizard which a visual way
to create charts (you picked the diagram type, the table data, etc).
But since it's not been working for ages now, it's better to remove it. We'll
need to decide if we want that back at some point.
Apart from this I don't think we'll loose anything.
Thanks
-Vincent
Hi,
This vote is about adding the following three clirr excludes:
* This interface is completely refactored:
<exclude>org/xwiki/chart/model/ChartModel</exclude>
* This class is removed:
<exclude>org/xwiki/chart/model/DefaultChartModel</exclude>
Was this class supposed to be public before or was it an error?
* The constants 'SOURCE' and 'PARAMS' are removed from this interface:
<exclude>org/xwiki/rendering/macro/chart/ChartDataSource</exclude>
The question is: is there a reasonably easy way to not cause backward compat breakages
for those classes?
From what I see this miss creating completely new interfaces for at least:
ChartModel
ChartGenerator
DataSource
ChartDataSource
So in essence this means deprecating lots of classes in xwiki-platform-chart-renderer and
introducing lots of new ones (although they can share common code).
So I think it's a bit too much work for the problem at hand since this API is not one
of the most used API and this is likely to not impact many users.
Also:
* The chart module is not used anywhere else in the platform except in oldcore by the old
chart plugin
* I'd like use to deprecate and retire the old chart plugin Thus the chart macro and the other chart modules are
good candidates to be non core extensions and thus a user who really wants to stay on the
oldversion could do so (provided he doesn't use the old chart plugin).
I am refactoring the chart macro and the interface 'ChartModel' is could
previously only be used for producing table-like datasets, but the jfree chart library can
produce plots from a wide range of dataset types. So the new version of the interface is
instead used for delivering the dataset and the axis configuration to the chart
generator.
I have deliberately choosed to not try abstracting away the fact that the chart macro
uses the jfree chart library. Doing so would require introducing a large number of
wrapper classes that would duplicate the functionality existing classes and it would still
not be particularly easy to just plug in another chart library.
+1 to that
Here is my +1.
+1 too
Thanks
-Vincent
>
> Best Regards,
>
> /Andreas