|Summary:||CTPlotArea OOXML type needs a cleaner interface|
|Product:||POI||Reporter:||Greg Woolsey <gwoolsey>|
|Component:||XSSF||Assignee:||POI Developers List <dev>|
Description Greg Woolsey 2017-03-12 04:17:59 UTC
It has separate methods to get lists of all the different chart types it could possibly contain. These have many overlapping/common properties. It is really annoying to have to write code that explicitly names each list and calls the proper getXYZChartList() method, then call the same getTitle() method on each one, typed explicitly. There should be a common interface defining the common properties, perhaps even a hierarchy of interfaces, and chart/plot wrapper/handler class, at least for XSSF, if not common with HSSF, that can return a List of all the charts as implementations of the common interface(s) defining all the common methods/properties. Callers could still get at the underlying explicit types, but in many instances wouldn't care, and this would remove the need for a lot of boilerplate in consumer code. (I'm looking in particular at Vaadin Spreadsheet Charts, and the gyrations they had to go through to get chart definitions out of POI).
Comment 1 Nick Burch 2017-03-12 10:13:38 UTC
The CT classes are auto-generated from the official OOXML schemas. They therefore can't really be changed (and only properly changed with a time machine and a seat on the specification committee...) We generally shouldn't be exposing any CT classes through to end users, these should normally be wrapped up in friendly POI classes. If there's some missing, we should add that class, deprecate the raw CT class access, and possibly do some magic in our classes with xml processing to keep things common (if needed)
Comment 2 Greg Woolsey 2017-03-12 13:15:29 UTC
Yes, I know about the generated classes. I'm proposing I add the missing "nice" access for them
Comment 3 Alain Fagot Bearez 2018-09-28 02:10:41 UTC
I understand there are still many chart types that are not yet implemented under the XDDF component in 4.0.0. Many features have been badly and incompletely tested, when tested at all. Anyhow I would appreciate some feedback about the @Beta versions already available and the rough edges that are still present for your experimented use cases. Of special interest would be your "missing nice access for them"...