This release of the how-to outlines functionality included in a - development build of HSSF. Those looking for information on the - release edition should look in the poi-src for the release or at a +
This release of the how-to outlines functionality for 1.5. + Those looking for information on the release edition should + look in the poi-src for the release or at a previous edition in CVS tagged for that release.
This release allows numeric and string cell values to be written to - or read from an XLS file. Also in this release is row and column - sizing, cell styling (bold, italics, borders,etc), and support for - built-in data formats. New to this release is an event-based API - for reading XLS files. It differs greatly from the read/write API + or read from an XLS file as well as reading and writing dates. Also + in this release is row and column sizing, cell styling (bold, + italics, borders,etc), and support for built-in data formats. New + to this release is an event-based API for reading XLS files. + It differs greatly from the read/write API and is intended for intermediate developers who need a smaller memory footprint. It will also serve as the basis for the HSSF Generator.
@@ -57,10 +58,8 @@ org.apache.poi.hssf.usermodel.HSSFWorkbook.Sheets are created by calling createSheet() from an existing instance of HSSFWorkbook, the created sheet is automatically added in -sequence to the workbook. In this release there will always be at -least three sheets generated regardless of whether you have three -sheets. More than three sheets is probably not supported. Sheets do -not in themselves have a sheet name (the tab at the bottom); you set +sequence to the workbook. Sheets do not in themselves have a sheet +name (the tab at the bottom); you set the name associated with a sheet by calling HSSFWorkbook.setSheetName(sheetindex,"SheetName").
Rows are created by calling createRow(rowNumber) from an existing @@ -242,7 +241,7 @@ method (sheet.removeRow(hssfrow)) and create objects just as you would if creating a new xls. When you are done modifying cells just call workbook.write(outputstream) just as you did above.
An example of this can be seen in -org.apache.poi.hssf.dev.HSSF.
+org.apache.poi.hssf.dev.HSSF.HSSF now has a logging facility (using log4j - thanks jakarta!) +
HSSF now has a logging facility (using + commons logging) that will record massive amounts of debugging information. Its mostly useful to us hssf-developing geeks, but might be useful in tracking -down problems. By default we turn this off because it results in -unnecessary performance degradation when fully turned on! Using it is -simple. You need an hssflog.properties file (example listed below, -those familiar with log4j can customize this as they wish). You can -either put this in your home directory (or wherever the default -directory is on windows which I suspect is c:\windows) or you can put -it wherever you want and set the HSSF.log to the path ending in "/" -(or "\\" on windows). If for any reason HSSF can't find it, -you get no logging. If the log configuration dictates the logging be -turned off, you get no logging.
-Here is an example hssflog.properties (actually its not an example
-its mine):
-
So Why use commons logging rather than log4j? Well the following discussion from +the jakarta-general mailing list sums it up pretty well. (Thanks Morgan) +
+Here's the problem, as I see it. +
+Suppose Commons component A decides to adopt Log4J, Commons component B +decides to adopt LogKit, and Commons component C adopts JDK1.4 logging. +They will all minimally function with the right jars in the classpath. +However you (the end-user) are left with maintaining configuration for 3 +different logging APIs, which is tedious at best. When you take into +account cool features like variable log levels, Log4J appenders and the +like, you're pretty much guaranteed to swallow up useful configuration +options because sophisticated configurations are too difficult to maintain +over mutiple logging implementations. +
++Contrarily, if all three Commons components use a logging facade, you can +focus all your configuration efforts on one logging implementation. Sure, +there is a trade-off; you don't have access to all the features, and the +interface between the facade and the implementation must be maintained. But +the benefits are not just political; they potentially make the end-users +configuration much easier. +
+Even if all Commons components used the same logging implementation (Log4J +for example), other projects in Jakarta-land may choose otherwise. If you +add enough Jakarta projects to your environment, you eventually end up with +the scenario described above. It's a worthwhile effort to attempt a logging +solution that plays well with the Jakarta community at large. I think in +many cases the Commons Logging component can fill that role. +
++Refer to the commons logging package level javadoc for more information concerning how to +configure commons logging. +
This release is near feature freeze for the 1.0-beta. All -priorities refer to things we'll be adding in the next release -(probably 2.0). The 1.0-beta is scheduled for release in the mid to -late December timeframe. While it's way to early to say when the -2.0-beta will be released, my "gut" feeling is to aim for -around March and have at least the first three items.
-Current list of priorities:
-- NO WAY!
-Here is a list of some of the web sites that are proudly using Poi 1.X (in no particular order): -
- -- If you do not find your site here, make sure you tell us - (use the word "Livesites" in the email subject, confirm that - you want to be listed publicly, say which version of Poi, and do not - forget to tell us the URL). - We would like to see this list grow bigger every day :-) -
-Currently we don't have any sites listed that use Poi, but we're sure they're out there. + Help us change this. If you've + written a site that utilises Poi let us know. +
+ +This document was created before the POI components for @@ -275,10 +275,10 @@
| - Benefit + Benefit | - Supporting Features + Supporting Features |