You will also need to trace through the code to find the methods and properties referenced indirectly, via reflection, unfortunately. To avoid code duplication, Vaadin chose to access some properties of chart types via reflection where the properties are common to all charts, but not defined in a common interface. This is part of the legacy of the OOXML design, since XML schemas don't have inheritance. Good job finding my code without my follow-through, and happy Father's Day!
On Sun, Aug 13, 2017 at 7:40 PM Alain FAGOT BÉAREZ <abea...@for-scala.it> wrote: > Hi, > > @Greg: It was Brazilian Father’s Day today, so that I did not pick up tech > lists from bed… but only after my daughter was sleeping. > > I cloned and searched through the following code base: > https://github.com/WoozyG/spreadsheet/tree/ConditionalFormatting > > There I found no single reference to any `usermodel.charts.*` classes that > I am deprecating. This is good news for POI. Bad news for Vaadin people is > that they rely on some `@Internal` method that is leaking underlying > `CTChart` element. My feeling is that the public `getCTChart` method had > been introduced due to some flaws in the original design of the > `ss.usermodel.charts` API. I removed the need for it, from POI side. > > The rest of the Vaadin code that depends on XSSFChart requires access to > both `@Internal public CTChart getCTChart()` and `@Internal public > CTChartSpace getCTChartSpace()` due to the lack of `usermodel` API to wrap > these concepts. Searching through Google, I also found similar dependencies > on the same methods on XSLFChart in some open source projects. This may be > work for a distinct branch later on, until we could deprecate these two > methods. > > Best regards, > Alain > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > >
