Bug 60847 - CTPlotArea OOXML type needs a cleaner interface
Summary: CTPlotArea OOXML type needs a cleaner interface
Alias: None
Product: POI
Classification: Unclassified
Component: XSSF (show other bugs)
Version: 3.16-dev
Hardware: All All
: P2 enhancement (vote)
Target Milestone: ---
Assignee: POI Developers List
Depends on:
Reported: 2017-03-12 04:17 UTC by Greg Woolsey
Modified: 2021-02-08 16:19 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
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"...
Comment 4 Alain Fagot Bearez 2021-02-08 01:36:17 UTC
I would suggest to close this issue as the effort to build some common code to access charts from XSLF, XSSF and XWPF is now available as XDDF with its own new set of related bugs.
Comment 5 Dominik Stadler 2021-02-08 16:19:13 UTC
Then let's do that and create separate issues for things that are reported as remaining issues/bugs/...

Thanks for creating the XDDF base so we can provide charts in the different types of documents.