Re: XDDF implementation shared between XSSFChart and XSLFChart
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ÉAREZwrote: > 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 > >
Re: XDDF implementation shared between XSSFChart and XSLFChart
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
Re: XDDF implementation shared between XSSFChart and XSLFChart
Perhaps then it could be a parallel package to start, marked @Beta, independent of the two existing packages, aside from reusing things like enums perhaps. Projects could then explore it and use it as a common alternative. Once it is deemed stable enough to leave beat status we could then mark the existing packages @Deprecated and start planning for removal. Sounds like that could be a POI 4 type of move? If we have it alongside the existing ones to start it may be easier to gather feedback on the design and find ways to ease consumer code migration before freezing the API. I'll point you to the vaadin code on GitHub in my AM, too much work on my phone in bed. That's when everyone catches up on tech mailing lists, right? On Sat, Aug 12, 2017, 22:21 Alain FAGOT BÉAREZwrote: > Hi, > > @pjfanning: In the current state, delegating to the XDDF from the legacy > SS and XSSF implementation would not be feasible. Some constants were > defined in Enum types and I don’t know how to “redirect” an Enum value to > the new implementation of it. > > @Greg: I don’t know how deep your code goes throughout the CT* side. For > the user model, I tried to put as much as possible of the common code in > the abstract XDDFChartData, XDDFChartData.Series and XDDFChartAxis, with > concrete implementations in the subclasses. If you could point me to some > repository where I could take a look at your current uses of chart related > CT* internals, I could focus on preparing a user model API for these uses. > > @Andi: I did not put any @Removal on the @Deprecated elements. Maybe all > the classes in the XDDF package should be marked as @Beta as well. > > Best regards, > Alain > - > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > >
Re: XDDF implementation shared between XSSFChart and XSLFChart
Hi, @pjfanning: In the current state, delegating to the XDDF from the legacy SS and XSSF implementation would not be feasible. Some constants were defined in Enum types and I don’t know how to “redirect” an Enum value to the new implementation of it. @Greg: I don’t know how deep your code goes throughout the CT* side. For the user model, I tried to put as much as possible of the common code in the abstract XDDFChartData, XDDFChartData.Series and XDDFChartAxis, with concrete implementations in the subclasses. If you could point me to some repository where I could take a look at your current uses of chart related CT* internals, I could focus on preparing a user model API for these uses. @Andi: I did not put any @Removal on the @Deprecated elements. Maybe all the classes in the XDDF package should be marked as @Beta as well. Best regards, Alain - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
Re: XDDF implementation shared between XSSFChart and XSLFChart
Vaadin7 requires Java 7, Vaadin 8 requires Java 8, so they are OK there. POI 3.17 already has breaking changes, so they have to put off incorporating my work until a larger release anyway, due to possible customer dependencies. Their next release will at least be using 3.16, so users like me can drop in a POI version up through 3.17 before more referenced deprecated APIs are removed. As I diagram it more on my end, and work through the details, I suppose putting this in 3.17 might be fine on all fronts, as long as the changes follow the POI guidelines of deprecating but not removing methods and classes. It just means a fair amount of rework for me on my dependent projects and contributions, whenever it happens. There is a lot of code around OOXML charts in my project and Vaadin's. I suppose that means others will have the same issue - if we radically change things up, it will break a lot of code for a lot of people. Designing and planning such a move should be done carefully, APIs are about the hardest thing to do well, and require a lot of up-front design work, I've found. I'll start by finding some free time to look at the pull request, and see how much it breaks things for me. On Fri, Aug 11, 2017 at 3:03 PM Andreas Beekerwrote: > > I would prefer this wait until 3.18, for purely selfish reasons, as we've > > already released a beta for 3.17. > > The postponing is ok for me ... but afterwards you have the breaking > changes anyways > and the Vaadin guys (or you?) have to do the chart modifications twice ... > or Vaadin > might be stuck on 3.17 ... > > On the other hand ... I don't know to what degree POI is part of Vaadin, > but POI 4.0 would > lift the Java minimum [1] > > Andi > > [1] > https://vaadin.com/vaadin-documentation-portlet/framework/installing/installing-java.html > >
Re: XDDF implementation shared between XSSFChart and XSLFChart
> I would prefer this wait until 3.18, for purely selfish reasons, as we've > already released a beta for 3.17. The postponing is ok for me ... but afterwards you have the breaking changes anyways and the Vaadin guys (or you?) have to do the chart modifications twice ... or Vaadin might be stuck on 3.17 ... On the other hand ... I don't know to what degree POI is part of Vaadin, but POI 4.0 would lift the Java minimum [1] Andi [1] https://vaadin.com/vaadin-documentation-portlet/framework/installing/installing-java.html
Re: XDDF implementation shared between XSSFChart and XSLFChart
That might work for me, I'm not sure. Here's more background. There is much I want to do with the charts API already, but I haven't had time to see if this change goes in directions I'm wanting already. In particular I am constantly having to do variations on "instanceof" and type casting and/or use reflection to retrieve elements common to most or all chart types but defined without a common interface or type hierarchy. The current design follows the OOXML definitions, which have much overlap and duplication but don't lend themselves to identifying common attributes. I've started doing some of that with a parent class for axes, but there needs to be more. This XDDF work could help that, and at worst would likely only move the work to a different package, not add to it. Delegating the public API, however, may break the necessary introspection and accessing of CT* classes done currently by both my own project and Vaadin-Spreadsheet-Charts. That would be a serious problem, as I'm having to walk a very fine line already with them - they don't dedicate a lot of resources, and I'm having to do all the heavy lifting, but I'm a one-person operation, in charge of all of development and IT for my employer. The project using POI is only supposed to be half my time :) Without testing it, I don't know yet how extensive the changes would be and how much backward compatibility would be broken, especially given that some of that compatibility uses reflection to access fields not necessarily already made public, because not all chart features are accessible from the POI API. On Fri, Aug 11, 2017 at 9:16 AM Javen O'Nealwrote: > That sounds like a good compromise. > > On Aug 11, 2017 04:18, "pj.fanning" wrote: > > > Would it be feasible to keep the existing classes and APIs and have them > > delegate to the XDDF impl? > > We could immediately deprecate any of these legacy APIs. > > > > > > > > -- > > View this message in context: http://apache-poi.1045710.n5. > > nabble.com/XDDF-implementation-shared-between-XSSFChart-and-XSLFChart- > > tp5728473p5728476.html > > Sent from the POI - Dev mailing list archive at Nabble.com. > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > > For additional commands, e-mail: dev-h...@poi.apache.org > > > > >
Re: XDDF implementation shared between XSSFChart and XSLFChart
That sounds like a good compromise. On Aug 11, 2017 04:18, "pj.fanning"wrote: > Would it be feasible to keep the existing classes and APIs and have them > delegate to the XDDF impl? > We could immediately deprecate any of these legacy APIs. > > > > -- > View this message in context: http://apache-poi.1045710.n5. > nabble.com/XDDF-implementation-shared-between-XSSFChart-and-XSLFChart- > tp5728473p5728476.html > Sent from the POI - Dev mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > >
Re: XDDF implementation shared between XSSFChart and XSLFChart
Would it be feasible to keep the existing classes and APIs and have them delegate to the XDDF impl? We could immediately deprecate any of these legacy APIs. -- View this message in context: http://apache-poi.1045710.n5.nabble.com/XDDF-implementation-shared-between-XSSFChart-and-XSLFChart-tp5728473p5728476.html Sent from the POI - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org
Re: XDDF implementation shared between XSSFChart and XSLFChart
I'm all for standardizing the API between modules, however I have a large amount of code using the current XSSF API, in conjunction with another library, Vaadin-Spreadsheet. I'm in the process of submitting a large change request to that group , adding my features to their product. They already are slow to adopt POI updates when APIs have breaking changes. I'm worried a large change to 3.17 will disrupt my work there, now that I've finally got their attention. I would prefer this wait until 3.18, for purely selfish reasons, as we've already released a beta for 3.17. Greg On Fri, Aug 11, 2017, 03:14 kiwiwingswrote: > Hi Alain, > > I have this issue on my todo-/watchlist, but I currently haven't got much > time for POI. > So if no-one else jumps in, you can ping me. > > We haven't yet started with the preparations for 3.17 final/4.0 - so I > think, we'll get that one in before. > > Best wishes, > Andi > > > > -- > View this message in context: > http://apache-poi.1045710.n5.nabble.com/XDDF-implementation-shared-between-XSSFChart-and-XSLFChart-tp5728473p5728474.html > Sent from the POI - Dev mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org > For additional commands, e-mail: dev-h...@poi.apache.org > >
Re: XDDF implementation shared between XSSFChart and XSLFChart
Hi Alain, I have this issue on my todo-/watchlist, but I currently haven't got much time for POI. So if no-one else jumps in, you can ping me. We haven't yet started with the preparations for 3.17 final/4.0 - so I think, we'll get that one in before. Best wishes, Andi -- View this message in context: http://apache-poi.1045710.n5.nabble.com/XDDF-implementation-shared-between-XSSFChart-and-XSLFChart-tp5728473p5728474.html Sent from the POI - Dev mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@poi.apache.org For additional commands, e-mail: dev-h...@poi.apache.org