Re: Getting book from sheet, sheet from row, etc.

Tue, 16 Dec 2008 11:17:43 -0800 

Thanks for raising this topic.

The absence of the requested methods has historical explanation.
In older versions of POI (I think prior to 3.0) the parent reference was not passed to HSSFSheet and HSSFRow. I think it is the only reason why HSSFSHeet.getWorkbook() and HSSFRow.getSheet() are missing. 


There was a lot of refactoring since then. HSSFSheet, HSSFRow and HSSFCell are now aware about their parent objects and 
I don't see why we shouldn't add the "getters".


Yegor

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]





---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]























					Reply via email to