Hi Andi,
thank you for your answer to my suggestions. I didn't modify the source
code yet, but I'd like to give it a try. My question about that is how I
should supply the patches: all-in-one or some small patches for each
type of change (e.g. adding enum parameter methods, unify naming, ...)?
Is there any Eclipse Code Style Template for this repository to use?
I have another XSSF question: Why is the number of conditional
formatting rules limit to 3 at
XSSFSheetConditionalFormatting:addConditionalFormatting(CellRangeAddress[],
ConditionalFormattingRule[])? I saw that HSSF has the same limitation,
but does this still apply to XSSF and isn't it just a copy&paste error
(as the code looks quite similar)? Secondly, is there an easy way to use
custom colors in conditional formatting?
Thank you for your help,
Johannes
Am 25.01.2014 01:19, schrieb Andreas Beeker:
Hi Johannes,
if none of the other committers object, I'll add those modifications
which you've mentioned.
Although I don't think these convenience methods will change the API
to be so much easier,
so that one doesn't need to check the help anymore, I'd like to brush
up the ss-usermodel
classes which come with an ole/hssf odour (e.g. short parameters) ;)
If you already have applied the changes on your developer box, please
create a bugzilla entry
and add a patch - otherwise I'll create a patch when I have time.
I won't apply the changes right away to the repo, as the 3.10 final
hasn't been released yet
and I'd like to use the bugzilla entry to give it a bit of ripening ...
Best wishes,
Andi
On 23.01.2014 18:40, Johannes Kinscher wrote:
Hello POI developers,
first of all I would like to thank you for the effort of making a
great library that makes developing Office files much easier that
automating (Microsoft) Office via COM will ever be. It's nice to have
such a stable and grown library around.
The reason I'm writing is that I'm using POI now for more than two
years and I'd like to make some improvements to the API regarding
spreadsheets (XSSF/HSSF). The problem in most cases is, that the API
contains non-intuitive ways of doing things regarding to the current
default usage of APIs (>=Java 1.5). In short the problems contain:
inconsistent usage of Enums, irritating constants and mostly a lot of
lines that are needed to achieve something small. I suggest some
changes that aim to make the usage of XSSF/HSSF much easier and avoid
a lot of search in the help which is necessary because of
unintutional API style. The major changes would be e.g.
- convert short parameters to int to remove bulky short casts
- create enums for constants (e.g. BorderStyle) and change parameter
types for methods to use it
- convert fields to real enums (e.g. Row.CREATE_NULL_AS_BLANK which
should be Cell.CREATE_NULL_AS_BLANK anyhow)
- advance interfaces (e.g. Color with no methods) to simplify
HSSF/XSSF usage
- create ease methods, e.g. cellStyle.setBorderTop(BorderStyle,
Color), cellStyle.setBorders(BorderStyle, Color),
cellStyle.setBorder(BorderSide, BorderStyle),
cellStyle.setBorder(BorderSide, BorderStyle, Color)
- unify naming, e.g. cellStyle.setLeftBorderColor vs.
cellStyle.setBorderLeft
- create ease "constructors", e.g. workbook.createFont(Font cloneFont)
- create range operations, e.g. cellRangeAddress.forEach(CellMethod)
All these changes would leave the default behaviour as-is and would
not break any existing code. Nevertheless, some things should be
marked as deprecated afterwards to indicate the new unified "valid"
behavior.
I'd like to ask about your opinion of these changes and the future
plans of the XSSF/HSSF support (if they already include and/or
conflict with some of these changes).
Regards,
Johannes
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]