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]
