Fully understand the 'philospohical' objection - and having read Yegor's latest post it seems the reason is an historical one anyway and can easilly be solved by adding the getter methods. Must admit however that faced with your problem I would have created overloaded methods in my utilities class - one that accepted a Workbook and one that did not.
--- On Tue, 12/16/08, Robins, Joe <[email protected]> wrote: From: Robins, Joe <[email protected]> Subject: RE: Getting book from sheet, sheet from row, etc. To: "POI Users List" <[email protected]> Date: Tuesday, December 16, 2008, 9:53 AM I can elaborate a bit more on the situation at hand. We're working on a reporting system which generates a wide variety of reports and exports them as Excel (which we generate with Poi). There are several different places where reports can be generated, so we extracted some of the common functionality (e.g. getting a row from a sheet, and automatically creating it if it doesn't exist yet, or writing data to a cell and setting the cell format appropriately based on the data type) to a PoiUtils class. The methods on this util class take arguments of the objects needed to do their work. We couldn't easily make a class variable of the Workbook, because it's coming from a variety of different places, and the util class wouldn't know where to look. And we could pass the workbook in to every single method, but since it's only in a few rare cases that we need it, that seems like unnecessary overhead for most of these methods. However, in the case where I'm currently finding myself needing it, it would not be easy to pass it in without modifying a number of other methods as well. That aside, I don't understand philosophically why these methods don't exist. A row does not exist without a sheet, and even maintains an internal reference to that sheet; why should I not be able to ask a row what its sheet is? (If I were looking at a spreadsheet in Excel, I could certainly determine the sheet for a row, the row for a cell, etc.) Joe Robins Director, Systems & Software Development Teach For America Email: [email protected] Phone: 212-279-2080, x368 >One day, all children in this nation will have the opportunity to attain an excellent education. http://www.teachforamerica.org/ -----Original Message----- From: Anthony Andrews [mailto:[email protected]] Sent: Tuesday, December 16, 2008 11:51 AM To: POI Users List Subject: RE: Getting book from sheet, sheet from row, etc. I must admit Joe that when I read your question I thought why? When I create or open a Workbook, I have the object at hand then and there. If I want it to be available to other methods, then I have two options, create the Workbook as a class variable (possible data coupling objections I know) or simply pass it to the method that requires it. Having said that, I do not have any idea if the original developers of the API had an objection to exposing the HSSFWorkbook object that is held within classes like HSSFSheet. --- On Tue, 12/16/08, Robins, Joe <[email protected]> wrote: From: Robins, Joe <[email protected]> Subject: RE: Getting book from sheet, sheet from row, etc. To: "POI Users List" <[email protected]> Date: Tuesday, December 16, 2008, 7:32 AM Following up to myself, since there hasn't been any response here, now with a slightly different question: If I wanted to submit a change to add these methods, is there any reason why anyone might object? This strikes me as an exceedingly useful thing to have, and very simple to do. But if there's some philosophical objection that will cause this to be rejected, then I wouldn't want to put time into working on it. Joe Robins Director, Systems & Software Development Teach For America Email: [email protected] Phone: 212-279-2080, x368 >One day, all children in this nation will have the opportunity to attain an excellent education. http://www.teachforamerica.org/ -----Original Message----- From: Robins, Joe [mailto:[email protected]] Sent: Monday, December 08, 2008 3:28 PM To: [email protected] Subject: Getting book from sheet, sheet from row, etc. Hi, I've tried to find this answer in the docs, looking through the archives, etc., but I can't find it anywhere. I'm hoping someone here can help me out. Is there a reason that there are not methods on HSSFSheet, HSSFRow, etc., to get the parent object? A quick look through the code reveals that they are storing those references. If I have: HSSFWorkbook wb = <create my workbook here> HSSFSheet sheet = wb.createSheet(); HSSFRow row = sheet.createRow(0); It would seem that I should be able to do: row.getSheet(); sheet.getWorkbook(); As I mentioned, they are storing these references in private member variables. Is there some reason they are not exposed through getters? Here is the use case that I am trying to accomplish. I have a method foo that takes as arguments an HSSFRow, a column number, and an Object, does some stuff, and writes the object to the specified cell: public void foo(HSSFRow row, int col, Object data); Now the problem is that I need to do some formatting depending on the type of data. If it's a number, for example, I set the cell type to NUMERIC. But if it's a Date, I want to create a cell style for the date to format it appropriately. However, I can only create a data format and a cell style off the workbook, not off the row or the cell, and I can't get a reference to the workbook at this point. So is there some reason I can't work my way back up the chain to get the workbook? And is there any other way to accomplish this, short of creating the style in the calling method and passing it in? Thank you, Joe Robins Director, Systems & Software Development Teach For America Email: [email protected] Phone: 212-279-2080, x368 One day, all children in this nation will have the opportunity to attain an excellent education. http://www.teachforamerica.org/ ____________________________________________ This communication and any file transmitted with it may contain information that is confidential, privileged and exempt from disclosure under applicable law. It is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are hereby notified that any use, dissemination or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender. Thank you for your cooperation. ____________________________________________ This communication and any file transmitted with it may contain information that is confidential, privileged and exempt from disclosure under applicable law. It is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are hereby notified that any use, dissemination or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender. Thank you for your cooperation. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] ____________________________________________ This communication and any file transmitted with it may contain information that is confidential, privileged and exempt from disclosure under applicable law. It is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are hereby notified that any use, dissemination or copying of this communication is strictly prohibited. If you have received this communication in error, please notify the sender. Thank you for your cooperation. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
