Spreadsheet Chart conversion code is all private/static, and can't be extended

[WoozyG]

I want to fix bugs/convert more chart formatting properties, but I'm struggling to do so because I have to either copy Vaadin code or rewrite my own logic. This particular piece is obviously slapped on from a custom contract engagement, and not designed at all to be used as a library by Pro Tools customers like me.

I would like to be part of the discussion for opening up the API and reworking it for reasonable customer extension.

[MTzukanov]

Hi WoozyG,

Can you provide more details on what you you like to perform and what prevents you from doing it. We might think of a solution together.

Regards

[WoozyG]

Yes. I will think more about this and provide some detailed feedback on how it could be structured. Overall goal is to easily extend the default Vaadin chart conversion code to:

1. Add additional chart property conversions as needed not yet supported by Vaadin's conversion
2. Customize things like chart styles to match project look and feel
3. override Vaadin conversion behavior to fix bugs before they are incorporated into a Vaadin release

Currently I have to copy classes and deploy them to a location seen earlier by the class loader, but that means maintaining copied code.

I think a good strategy could involve the Java SPI facilities, for defining custom factory classes for various pieces of the conversion code.

[WoozyG]

Perhaps a way to specify a handler/converter for each major piece, with interfaces that accept a POI document component class plus the corresponding Vaadin configuration class. That way customers can write subclasses of Vaadin default classes that call super() to do the basic conversions, and then augment with custom business logic and additional Excel/chart properties if not supported by the default yet.

I'm thinking of things at these levels:

1. XAxis
2. YAxis (maybe generic with Xaxis?)
3. Category names
4. Series data
5. Chart styling
6. Legend info

One goal would be to design extensible interfaces such that users would not need to write a second pass through the Excel components to handle additional features, and manually align their work with the automatically converted configuration pieces from the framework, such as axis/series order, etc.

[WoozyG]

Also, if you have ideas for improving the POI API such that access to the generated CT classes isn't needed, and common properties can be accessed via common interfaces across different CT types, let me know, and I'll see if I can get something like that into the 3.16 POI release.